summaryrefslogtreecommitdiff
path: root/drivers/usb
AgeCommit message (Collapse)AuthorFilesLines
2026-08-14usb: gadget: uvc: Fix null pointer dereference in uvcg_video_init()Jeffin Philip1-1/+1
In uvcg_video_init(), if kthread_run_worker() fails, the error logged uses uvcg_err(), however, the pointer it uses: video->uvc is not assigned at this point, triggering a null pointer dereference. Fix this by directly using uvc->func which is assigned already. Reported-by: syzbot+8dcac923582c28505fd7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8dcac923582c28505fd7 Fixes: f0bbfbd16b3b ("usb: gadget: uvc: rework to enqueue in pump worker from encoded queue") Cc: stable@vger.kernel.org Signed-off-by: Jeffin Philip <jeffinphilip14@gmail.com> Reviewed-by: Xu Yang <xu.yang_2@nxp.com> Link: https://patch.msgid.link/20260804034338.7976-1-jeffinphilip14@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14usb: typec: thunderbolt: Disable work before freeing tbt on removeFan Wu1-0/+2
tbt_altmode_remove() drops the plug and cable references without draining tbt->work. The work function dereferences those references, and can also requeue itself in its error path. The VDM callbacks can queue the same work item. Disable and drain tbt->work before dropping the references. This waits for an existing invocation and prevents subsequent schedule_work() calls from queueing it during teardown. This issue was found by an in-house static analysis tool and confirmed by manual code review. Fixes: 100e25738659 ("usb: typec: Add driver for Thunderbolt 3 Alternate Mode") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260802014959.416687-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14usb: xhci: Handle bogus TRB pointers in Missed Service Error eventsMichal Pecio1-2/+16
xHCI 1.0 allowed these pointers to be zero. Some Intel chipsets from the era usually set it to zero, but sometimes (apparently) to the next TRB after the one referenced by the previous transfer event on the endpoint. Usually that's indeed the missed TD, but it may also be the last TRB of a two-TRB TD already completed with Short Packet on its first TRB. Then the driver skips all pending TDs, failing to find a match. When handling Missed Service Error, scan TD list twice and only really skip TDs in the second pass if the first pass found a match. This won't catch bogus pointers to wrong TDs, but such a bug would be practically impossible to detect automatically and isn't known to exist. Reported-by: Bart Nagel <bart@tremby.net> Closes: https://lore.kernel.org/linux-usb/al_hchyOdPoPWKEo@spiral/ Suggested-by: Mathias Nyman <mathias.nyman@linux.intel.com> Fixes: d0b619599e52 ("usb: xhci: Expedite skipping missed isoch TDs on modern HCs") Cc: stable@vger.kernel.org Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-18-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14usb: xhci: Handle USB3 port events when there is one roothubSemih Baskan1-1/+1
handle_port_status() drops every USB3 port event when xhci->shared_hcd is NULL. The check dates from a time when xhci-plat always created a shared hcd, so a NULL one could only mean the hcd had been removed. Since commit 4736ebd7fcaf ("usb: host: xhci-plat: omit shared hcd if either root hub has no ports") that is no longer true. A controller whose USB2 root hub has no ports gets a single roothub, the USB3 rhub is served by the main hcd, and shared_hcd stays NULL for the lifetime of the device. Every SuperSpeed port event is then thrown away as bogus behind a debug message, so devices never enumerate even though the port sees the device and its change bits stay set: 0x006a1203 Powered Connected Enabled Link:U0 PortSpeed:4 Change: CSC WRC PRC PLC Broadcom Northstar is such a controller. USB3 works there up to 5.15 and stops working from 5.19 onwards. Ask xhci_get_usb3_hcd() instead. It returns the shared hcd when there is one, the main hcd when the USB2 root hub has no ports, and NULL once the shared hcd is gone, which keeps the original meaning of the check. Tested on an Asus RT-N18U (BCM47081), which has a single roothub. Before the change nothing enumerates on the USB3 port; after it SuperSpeed devices enumerate normally over repeated connect and disconnect cycles, the change bits shown above clear, and USB2 is unaffected on both ports. Fixes: 4736ebd7fcaf ("usb: host: xhci-plat: omit shared hcd if either root hub has no ports") Cc: stable@vger.kernel.org Signed-off-by: Semih Baskan <strst.gs@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-17-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14usb: xhci: replace Unicode quotes with ASCII apostrophesNiklas Neronin2-2/+2
Non-ASCII characters trigger git send-email to prompt for encoding on each modification near them, which is unnecessary and annoying. Using plain ASCII avoids these prompts and does not change its meaning. This change only affects comments and has no functional impact. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-16-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14usb: xhci: remove redundant 'xhci' pointer from endpoint structNiklas Neronin4-32/+27
The 'xhci_virt_ep' struct currently contains a pointer to its parent 'xhci_hcd' struct. Since all endpoint-related structs are contained within 'xhci_hcd', this pointer is redundant. Remove the 'xhci' pointer from 'xhci_virt_ep' and instead pass it explicitly to functions that require it, as some already do it. This change reduces unnecessary complexity and aligns the code with the rest of the xhci driver. Memory impact: For each device connected a struct 'xhci_virt_device' is allocated, this struct conatains a 31 slot array of struct 'xhci_virt_ep'. A USB hub consumes 1 slot, but every downstream device consumes another slot. This means that the total memory saved buy this patch is: Devices * 31 * 8 bytes Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-15-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14usb: xhci: remove redundant function wrapperNiklas Neronin1-14/+6
The function ring_doorbell_for_active_rings() rings the doorbell for any rings with pending URBs. It has a trivial wrapper, xhci_ring_doorbell_for_active_rings(), which takes the same arguments and simply calls the former. Since the wrapper adds no functionality, remove it and rename ring_doorbell_for_active_rings() to xhci_ring_doorbell_for_active_rings(). Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-14-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14usb: xhci: use 64-bit Addressing Capability macroNiklas Neronin1-1/+1
Simplify by replace BIT(0) call with its relevant macro. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-13-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14usb: xhci: standardize multi bit-field macrosNiklas Neronin12-43/+57
This patch aims to unify the format of register macros and masks within the xHCI driver. Currently, register macros have inconsistent bit-field masks, get macros, and set macros, with varying naming conventions and functionalities. ==================== Proposal ==================== * Introduce a standardized approach by using only mask macros for each bit field, leveraging GENMASK() for enhanced clarity. #define HCC_MAX_PSA GENMASK(15, 12) * Utilize FIELD_GET() and FIELD_PREP() macros directly in the C code for getting and setting values, ensuring consistency and readability. u32 psa = FIELD_GET(HCC_MAX_PSA, reg); * Maintain exceptions for macros that perform custom operations. #define CTX_SIZE(_hcc) (_hcc & HCC_64BYTE_CONTEXT ? 64 : 32) * Note, while FIELD_*() macros are beneficial, I am not suggesting that they should always be used. Instead, use them where they simplify the code and eliminate the necessity for custom get/set macros. In the example below, additional FIELD_PREP() or FIELD_MODIFY() is not beneficial. #define HCS_MAX_SCRATCHPAD(p) (FIELD_GET(HCS_MAX_SP_HI, (p)) << 5 | \ FIELD_GET(HCS_MAX_SP_LO, (p))) ==================== Improvements ==================== Simplified Macros: By reducing custom macros, the code becomes more straightforward. Macros FIELD_GET() and FIELD_PREP() are commonly used, which contributes to the code readability and consistency. $ git grep -n 'FIELD_GET' | wc -l 9027 $ git grep -n 'FIELD_PREP' | wc -l 15407 Consistent Return Type: All bit macros will return unsigned 64-bit values, mitigating potential cross-architecture issues. Unified Bit Range Definition: The mask macro will define bit ranges, eliminating separate definitions for get/set macros. Because, FIELD_GET() & FIELD_PREP() use mask macro. Cleaner header file with less macros: Fewer macros result in a cleaner and more manageable header file. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-12-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14usb: xhci: bail out of setup if the controller is inaccessibleBreno Leitao1-3/+8
xhci_gen_setup() locates the operational registers using the capability length read from the very first register: xhci->op_regs = hcd->regs + HC_LENGTH(readl(&xhci->cap_regs->hc_capbase)); If the controller is dead or has dropped off the bus, that read returns ~0, HC_LENGTH() truncates it to 0xff, and op_regs ends up 0xff bytes past the page-aligned MMIO base, i.e. unaligned. The first access through it, xhci_halt() -> xhci_handshake() reading op_regs->status, is then an unaligned readl() on device memory. arm64 faults on unaligned device accesses, so instead of xhci_handshake() catching the all-ones value and returning -ENODEV, setup oopses: xhci-pci-renesas 0005:08:00.0: Unable to change power state from D3cold to D0, device inaccessible xhci-pci-renesas 0005:08:00.0: xHCI Host Controller xhci-pci-renesas 0005:08:00.0: new USB bus registered, assigned bus number 1 Unable to handle kernel paging request at virtual address ffff80030a770103 ESR = 0x0000000096000021 FSC = 0x21: alignment fault Internal error: Oops: 0000000096000021 [#1] SMP pc : xhci_halt [xhci_hcd] Call trace: xhci_halt xhci_gen_setup xhci_pci_setup usb_add_hcd usb_hcd_pci_probe xhci_pci_common_probe xhci_pci_renesas_probe This was hit with a Renesas uPD720201 that failed to power up ("Unable to change power state from D3cold to D0, device inaccessible") yet still reached the HCD probe path. Read the capability register once, and if it reads back the all-ones value (as xhci_handshake() and xhci_reset() already test for), abort setup with -ENODEV before op_regs is derived from it. Reading it once also avoids re-reading a register that may change under a concurrent hot-removal. Fixes: 66d4eadd8d06 ("USB: xhci: BIOS handoff and HW initialization.") Cc: stable@vger.kernel.org Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-11-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14xhci: dbgtty: Drop extra call to idr_destroy()Lucas De Marchi1-5/+5
idr_destroy() is already called on error paths in dbc_tty_init(). Do not call it again on exit. For symmetry with the init side, also use IS_ERR_OR_NULL() to gate the exit steps. Signed-off-by: Lucas De Marchi <ldemarchi@nvidia.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-10-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14xhci: dbgtty: Fix unregister on tty_alloc_driver() failureLucas De Marchi1-5/+11
Make sure to set dbc_tty_driver to NULL to match the check in dbc_tty_exit(). For that, make detached error handling path common to the other branch in the same function. Fixes: 4521f1613940 ("xhci: dbctty: split dbc tty driver registration and unregistration functions.") Cc: stable@vger.kernel.org # v5.10 Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Lucas De Marchi <ldemarchi@nvidia.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-9-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14xhci: dbgtty: Fix unregister on tty_register_driver() failureLucas De Marchi1-0/+1
If tty_register_driver() fails, it drops the reference, but fails to set the global dbc_tty_driver to NULL, causing the unregister to be called again when module exits. On module unload dbc_tty_exit() only gates its cleanup on the driver pointer being non-NULL, so it operates on the already-freed driver: module_init(xhci_hcd_init) xhci_hcd_init() xhci_dbc_init() [return value ignored] dbc_tty_init() tty_register_driver() fails tty_driver_kref_put() -> driver freed (dbc_tty_driver left dangling) ... module_exit(xhci_hcd_fini) xhci_hcd_fini() xhci_dbc_exit() dbc_tty_exit() if (dbc_tty_driver) -> true (dangling) tty_unregister_driver() -> use-after-free Fixes: 4521f1613940 ("xhci: dbctty: split dbc tty driver registration and unregistration functions.") Cc: stable@vger.kernel.org # v5.10 Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Lucas De Marchi <ldemarchi@nvidia.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-8-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14xhci: move dequeue to next valid td instead of past cancelled oneMathias Nyman1-77/+63
If a ring stops on a TD that is about to be cancelled then the xHC ring hardware dequeue pointer needs to move past the TD to flush TRBs from xHC cache. The TRB after the cancelled TD might be a no-op TRB, or a link TRB. Moving the dequeue to a link TRB has caused isses on some hosts, and moving it to a no-op TRB can be an issue for control endpoints as xhci specification 4.8.3 'Endpoint Context State" states that The Default Control Endpoint shall return to the Running state when the Doorbell is rung for the next Setup Stage TD sent to the endpoint. Solve this by always moving the dequeue pointer to the next valid TD. If ring is empty and there are no queued TDs then move the dequeue pointer to the enqueue pointer. If enqueue points to a link TRB on a empty ring then propagate enqueue to next segment before pointing dequeue to it. Note that this patch ended up almost identical to a simplifiaction patch done earlier by Michal Pecio, see link. That patch was not added due to a potential, somewhat theoretical issue of moving dequeue backwards. Turns out improving cancelled control transfers end up with the same code, and is now worth taking. Code is very likely subconsciously based the patch by Michal Pecio. Link: https://lore.kernel.org/linux-usb/20250225125939.7a248e38@foxbook/ Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-7-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14xhci: avoid xHC endpoint changes after disconnect or link error.Mathias Nyman3-4/+21
Avoid all extra endpoint state changes after the roothub link is lost due to disconnect or link error, and endpoint is known to be in a non-running state. Rapid endpoint state changes involving endpoint reset, restart, and stopping the endpoint have caused xHC failures to complete stop endpoint command. xhci driver sees this as a fatal flaw and tears down xhci. These endpoint state changes are normally part of recovery from transaction errors or URB cancel. In this case recovery is not needed. Add an endpoint state called EP_DROP_PENDING. Set ep->ep_state |= EP_DROP_PENDING when an endpoint is found in a halted or stopped non-running state, and the roothub link is lost. Prevent endpoint from restarting. URB cancel doesn't need to stop the endpoint if EP_DROP_PENDONG is set. URBs can be given back directly. Endpoint is, and will remain stopped until it's dropped. Tested-by: Xu Rao <raoxu@uniontech.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14xhci: prevent endpoint recovery after roothub disconnectMathias Nyman2-4/+9
Prevent transfer retry and endpoint recovery if the device or its parent disconnected from the roothub. Just like link error case. There is a suspicion some xHC controllers may stop processing endpoint related commands after the last USB device disconnects from the host. Disconnect often causes transaction errors, xhci driver tries to (soft) reset and restart the endpoint to recover it. Hub driver again will cancel all pending URBs once disconnect is detected, stopping the endpoint right after (soft) reset restarted it. xHC controller sometimes fail to complete the stop endpoint command, leading to driver timing out, and tearing down xhci Prevent extra endpoint (soft) reset after xhci driver is aware of the parent roothub port disconnect. Tested-by: Xu Rao <raoxu@uniontech.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14xhci: include all root port children in recovery prevention on link errorMathias Nyman3-23/+17
Driver already prevents useless transfer retry and endpoint recovery for devices directly connected to a root port with link errors. These devices are either disconnecting or will be reset. Link is gone. Move the flag indicating link error from the xhci device structure to the root port strucure, allowing all child devices behind hubs to easily check for root port link errors, avoiding useless transfer retries and endpoint recovery. This extends the previous endpoint recovery prevention in commit b8c3b718087b ("usb: xhci: Don't try to recover an endpoint if port is in error state.") Only root port link errors can be detected early by xhci driver, not link errors between external hubs and their children. Tested-by: Xu Rao <raoxu@uniontech.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14xhci: Set frame ID field of isoc TRB when starting an isoch streamMathias Nyman1-7/+24
The frame id field can be set for the first TD of the first isoc URB to schedule the start of an isoc stream even in host doesn't support CFC (Contiguous Frame ID Capability) Set the frame ID TRB field of the first isoc TD unless URB has the schedule immediately 'URB_ISO_ASAP' transfer flag set. cc: Dylan Robinson <dylan_robinson@motu.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14xhci: fix frame id calculation and checks for isoc URBsMathias Nyman3-103/+85
Check if the expected frame IDs for a isochronous URB submitted mid stream is within the valid frame time window that xHC controller is capable of queuing TDs. The range only needs to be checked once per URB as the isoc TDs of an URB are queued in one go with spinlock held and interrupts disabled. Calculate the valid frame window start and end frame id in frames instead of microframes to better match how xhci specification section 4.11.2.5 does it. Don't add frame id gaps or change scheduling to SIA mid stream if the start frame is outside the valid frame winow. Only print a debug message. Some devices can't handle gaps in isochronous transfers. Calculate a valid start frame for the first URB of a stream, and align it to a full frame, or to interval start if interval is longer than a frame Set urb->start_frame value for every URB cc: Dylan Robinson <dylan_robinson@motu.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260806142113.2436238-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-14Merge tag 'usb-serial-7.3-rc1' of ↵Greg Kroah-Hartman6-218/+269
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next Johan writes: USB serial updates for 7.3-rc1 Here are the USB serial updates for 7.3-rc1, including: - fix digi_acceleport port registration order - stop digi_acceleport I/O when ports are closed - fix digi_acceleport OOB port dev_printk() - fix metro-usb unthrottle race - fix option slab OOB read with malicious devices - add support for a new class of Prolific PL256X devices Included are also various clean ups. All have been in linux-next with no reported issues. * tag 'usb-serial-7.3-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: pl2303: add support for PL256X multi-port devices USB: serial: option: fix slab OOB read in interrupt URB callback USB: serial: keyspan_pda: drop unused driver data usb-serial pointer USB: serial: metro-usb: drop redundant initialisations USB: serial: metro-usb: fix unthrottle race USB: serial: metro-usb: replace unnecessary atomic allocation USB: serial: digi_acceleport: fix oob port dev_printk() USB: serial: digi_acceleport: clean up inb command submission USB: serial: digi_acceleport: clean up write completion USB: serial: digi_acceleport: clean up xfer buf length expression USB: serial: digi_acceleport: drop unused in-buf define USB: serial: digi_acceleport: stop OOB I/O when not in use USB: serial: digi_acceleport: drop redundant driver data sanity checks USB: serial: digi_acceleport: clean up declarations and whitespace USB: serial: digi_acceleport: add oob port helper USB: serial: digi_acceleport: always stop write urb on close USB: serial: digi_acceleport: drop unused wait queue USB: serial: digi_acceleport: fix port registration order USB: serial: digi_acceleport: do not log stopping of urbs as errors
2026-08-14Merge tag 'usb-serial-7.2-rc7' of ↵Greg Kroah-Hartman2-15/+7
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next Johan writes: USB serial fixes for 7.2-rc7 Here is a fix for a long-standing issue in the spcp8x5 driver which syzbot just started hitting and a change adding lockdep annotation to digi_acceleport to suppress a false positive deadlock warning. Note that only the digi_acceleport commit has been in linux-next (and with no reported issues). * tag 'usb-serial-7.2-rc7' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: spcp8x5: drop broken carrier detect support USB: serial: digi_acceleport: add port lock nesting annotation
2026-08-14Merge 7.2-rc7 into usb-nextGreg Kroah-Hartman8-22/+55
We need the USB fixes in here as well to build on top of. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-13Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski7-22/+53
Cross-merge networking fixes after downstream PR (net-7.2-rc8). No conflicts. Adjacent changes: drivers/net/ethernet/wangxun/ngbe/ngbe_main.c 5f3a13e0bb5e ("net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling") d661abdc30c2 ("net: ngbe: correct misleading interrupt comment") drivers/net/ipvlan/ipvlan_main.c e16e960d55a4 ("ipvlan: inherit needed_headroom and needed_tailroom from phy_dev") 00a40d809207 ("ipvlan: Support per-netns netdev unregistration.") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-10Merge tag 'soc_fsl-7.3-1' of ↵Arnd Bergmann1-0/+1
https://git.kernel.org/pub/scm/linux/kernel/git/chleroy/linux into soc/drivers FSL SOC Changes for 7.3 Freescale QUICC Engine: - Use generic I/O helpers in interrupt controller for IO Ports - Move CONFIG_QE_GPIO out of powerpc - Fix DT scan for GPIO nodes - Convert IO ports interrupt controller to generic IRQ chip - Add support of IRQs in GPIO controller - Implement get_direction() in GPIO controller - Check platform_driver_register() in interrupt controller for IO Ports Data Path I/O: - Replace maintainer - Remove redundant dev_err() - Fix kernel-doc typos Freescale Management Complex: - Use strscpy() to copy strings into arrays - Remove redundant dev_err() - Drop unused assignment of acpi_device_id::driver_data Other changes: - Add kernel and device tree binding support for RCW override, completing the SerDes PHY driver functionality - Fix kernel-doc warnings and typos in DPAA header * tag 'soc_fsl-7.3-1' of https://git.kernel.org/pub/scm/linux/kernel/git/chleroy/linux: (31 commits) bus: fsl-mc: drop unused assignment of acpi_device_id::driver_data soc: fsl: qe: check platform_driver_register() in qe_ic_of_init() phy: lynx-10g: use RCW override procedure for dynamic protocol change soc: fsl: guts: implement the RCW override procedure dt-bindings: fsl: layerscape-dcfg: define DCFG_DCSR region soc: fsl: guts: make fsl_soc_data available after fsl_guts_init() soc: fsl: guts: make it easier to determine on which SoC we are running soc: fsl: guts: add a central fsl_guts_read() function soc: fsl: guts: add a global structure to hold state soc: fsl: guts: use a macro to encode the DCFG CCSR space soc: fsl: guts: perform fsl_guts_init() error teardown in reverse order of setup soc: fsl: dpio: fix kernel-doc typos soc: fsl: fix kernel-doc warnings and typos bus: fsl-mc: Remove redundant dev_err() soc: fsl: qe: Add support of IRQs in QE GPIO soc: fsl: qe: Rename irq variable to parent_irq soc: fsl: qe: Convert to generic IRQ chip soc: fsl: qe: Handle spurious interrupts soc: fsl: qe: Iterate over all pending interrupts in cascade handler soc: fsl: qe: Use generic_handle_domain_irq() ... Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-08-10Merge tag 'v7.2-rc7' into driver-core-nextDanilo Krummrich86-448/+1109
We need the driver-core fixes in here as well to build on top of. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-08-07USB: serial: spcp8x5: drop broken carrier detect supportJohan Hovold1-13/+0
The driver does not support modem status notifications and instead used to fetch the modem status once at open() and subsequently operate on and report stale state. As part of fixing this, a call to fetch the status was added to carrier_raised(), which does not work as that callback must not sleep (e.g. unlike tiocmget()). Drop the broken carrier detect support. Fixes: e1ed212d8593 ("USB: spcp8x5: add proper modem-status support") Cc: stable@vger.kernel.org # 3.10 Reported-by: syzbot+3b514b87202742f22c44@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/6a73cea2.01d0871a.3a0d52.000d.GAE@google.com Signed-off-by: Johan Hovold <johan@kernel.org>
2026-08-06usb: atm: cxacru: fix use-after-free in cxacru_poll_statusNguyen Quang Le Kien1-9/+1
In cxacru_unbind(), cancel_delayed_work_sync() was conditionally skipped when poll_state was CXPOLL_STOPPED. However, a work item previously scheduled when poll_state was CXPOLL_POLLING may still be pending in the workqueue at the time poll_state transitions to CXPOLL_STOPPED. Skipping cancel_delayed_work_sync() in this case allows the work to fire after cxacru_data is freed, causing a use-after-free when cxacru_poll_status() attempts to acquire instance->poll_state_serialize. Fix this by always calling cancel_delayed_work_sync() regardless of poll_state, ensuring no pending or in-flight work can access the freed instance. Cc: stable+noautosel@kernel.org # untested fix to a driver init path race Reported-by: syzbot+24eb38c789655fc43663@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=24eb38c789655fc43663 Signed-off-by: Nguyen Quang Le Kien <khiemtranzo532001@gmail.com> Link: https://patch.msgid.link/20260803101716.2592486-1-khiemtranzo532001@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06usb: atm: cxacru: properly kill rcv_urb on error in cxacru_cm()Aleksandr Nogikh1-0/+2
If cxacru_cm() encounters an error while submitting or waiting for snd_urb, it aborts and returns the error without killing the already submitted rcv_urb. This leaves the rcv_urb active. When this happens during initialization (e.g., in cxacru_atm_start()), the driver may ignore the error and proceed to call cxacru_poll_status(), which invokes cxacru_cm() again. Attempting to submit the still-active rcv_urb triggers a warning in usb_submit_urb(): cxacru 1-1:1.0: send of cm 0x84 failed (-104) ATM dev 0: cxacru_atm_start: CHIP_ADSL_LINE_START returned -104 ------------[ cut here ]------------ URB ffff88812658d200 submitted while active WARNING: drivers/usb/core/urb.c:379 at usb_submit_urb+0x79/0x18b0 drivers/usb/core/urb.c:379 ... Call Trace: <TASK> cxacru_cm+0x21a/0xf10 drivers/usb/atm/cxacru.c:631 cxacru_cm_get_array drivers/usb/atm/cxacru.c:722 [inline] cxacru_poll_status+0x178/0x1110 drivers/usb/atm/cxacru.c:828 cxacru_atm_start+0x185/0x360 drivers/usb/atm/cxacru.c:814 usbatm_atm_init+0x144/0x3a0 drivers/usb/atm/usbatm.c:927 usbatm_usb_probe+0x15cb/0x1db0 drivers/usb/atm/usbatm.c:1178 cxacru_usb_probe+0x17f/0x220 drivers/usb/atm/cxacru.c:1370 ... To fix this, ensure that rcv_urb is properly killed if cxacru_cm() aborts early. We can safely call usb_kill_urb() on rcv_urb in the error path, as it is safe to call even if the URB is not active (e.g., if it failed to submit in the first place, or if it already completed). Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path Reported-by: syzbot+c9dff578c3a41775176a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c9dff578c3a41775176a Link: https://syzkaller.appspot.com/ai_job?id=75fec6f2-c8a6-43b1-b184-4d26baba86cc Signed-off-by: Aleksandr Nogikh <nogikh@google.com> Link: https://patch.msgid.link/91edfa4c-a63d-400c-9f00-31f3e1f98c00@mail.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06usb: atm: ueagle-atm: fix array-index-out-of-bounds in uea_bind()Subasri S1-1/+2
Add a bounds check on the global variable modem_index before using it as an index in sync_wait[] array whose size is NB_MODEM. Cc: stable+noautosel@kernel.org # untested fix to a driver init path race Reported-by: syzbot+92f5bf49bf4ac75223ca@syzkaller.appspotmail.com Tested-by: syzbot+92f5bf49bf4ac75223ca@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=92f5bf49bf4ac75223ca Signed-off-by: Subasri S <subasris1210@gmail.com> Link: https://patch.msgid.link/20260802-usb-ueagble-atm-v1-1-340f085b04aa@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04usb: xhci: use BIT_ULL for CRCR bits to fix incorrect 64bit maskLachlan Hodges1-6/+6
xhci is unusable on some systems after driver switched to BIT() macro. Upper 32bits of 64bit CRCR command register are unintentionally cleared. Seen on a raspberry pi 4B compiled for arm32. The main symptoms were the following log message: [ 0.549897] raspberrypi-firmware soc:firmware: Attached to firmware from 2021-02-25T12:11:39 [ 0.626859] xhci_hcd 0000:01:00.0: xHCI Host Controller [ 0.626889] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 1 [ 0.812619] xhci_hcd 0000:01:00.0: hcc params 0x002841eb hci version 0x100 quirks 0x0000200000000890 [ 0.813188] xhci_hcd 0000:01:00.0: xHCI Host Controller [ 0.813203] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 2 [ 0.813219] xhci_hcd 0000:01:00.0: Host supports USB 3.0 SuperSpeed [ 0.813602] hub 1-0:1.0: USB hub found [ 0.814052] hub 2-0:1.0: USB hub found [ 0.952714] xhci_hcd 0000:01:00.0: ERROR mismatched command completion event Additionally running lsusb just hangs. Running the same kernel compiled for aarch64 worked fine. Bisected to the commit in the Fixes line. Additionally a USB device plugged in to the USB3.0 (or 2.0) did not enumerate. Once this patch is applied the USB device enumerates properly. The CRCR register is 64 bits wide - commit abe93f27cdd7 ("xhci: use BIT macro") changed the flag definitions from (1 << n), a signed int, to BIT(n), an unsigned long. Within xhci_set_cmd_ring_deq(), the following operation is performed on the CRCR register: ... crcr &= ~CMD_RING_PTR_MASK; crcr |= deq_dma; crcr &= ~CMD_RING_CYCLE; crcr |= xhci->cmd_ring->cycle_state; ... Previously, ~CMD_RING_CYCLE was ~(int)1, a negative signed value (0xFFFFFFFE with the sign bit set). Widening a negative signed int to u64 sign-extends it to 0xFFFFFFFFFFFFFFFE, correctly clearing only bit 0 and preserving the 64-bit pointer written two lines above. After the change when running on 32 bit kernels, ~CMD_RING_CYCLE is ~(unsigned long)1UL. On a 32-bit host this is an unsigned 32-bit value (0xFFFFFFFE, no sign bit). Widening an unsigned value to u64 zero-extends it instead (0x00000000FFFFFFFE), so the subsequent AND silently clears bits 63:32 of crcr, truncating the command ring pointer that was just written before the value reaches hardware. To fix, similar to how CMD_RING_PTR_MASK is defined, make sure we use the BIT_ULL variant when defining the CRCR bits. [Mathias: use BIT_ULL() for ERST_EHB and EP_CTX_CYCLE_MASK as suggested by Michal Pecio, also include raspberry case in commit message] Fixes: abe93f27cdd7 ("xhci: use BIT macro") Cc: stable <stable@kernel.org> Assisted-by: Claude:claude-sonnet-5 cc: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260804083639.2148950-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-03usb: quirks: Add ShanWan gamepad to quirk listIshaan Dandekar1-0/+3
The ShanWan Wireless Gamepad (dongle ID 2563:0575) crashes with a -71 EPROTO error during standard enumeration because it expects a 255-byte initial configuration request. Add this device to the quirk list to use the USB_QUIRK_WINDOWS_CONFIG_REQ_SIZE flag. Signed-off-by: Ishaan Dandekar <ishaan.dandekar@gmail.com> Cc: stable <stable@kernel.org> Link: https://patch.msgid.link/20260802120128.38302-1-ishaan.dandekar@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-03usb: hub: Split announce_device() to log device identity before enumerationNikhil Solanke1-4/+12
announce_device() currently logs the device VID:PID and string descriptors only after successful enumeration. This means that if enumeration fails, no identifying information about the device appears in the kernel log, making it difficult to diagnose failures. Split announce_device() into announce_device_ids(), which logs the VID:PID and bcdDevice immediately after the device descriptor is read, and announce_device_strings(), which logs the product, manufacturer, and serial number strings after successful enumeration. This ensures that a device's identity is always visible in the log regardless of whether enumeration succeeds or fails. Suggested-by: Michal Pecio <michal.pecio@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Nikhil Solanke <nikhilsolanke5@gmail.com> Link: https://patch.msgid.link/20260728195158.65162-3-nikhilsolanke5@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-03usb: core: Add quirk for 255-bytes initial config readNikhil Solanke2-8/+28
Certain third-party USB game controllers exposing (or spoofing) an Xbox 360-compatible interface (VID:PID 045e:028e) fail to enumerate under Linux. The device disconnects from the bus without responding to the initial GET_DESCRIPTOR(CONFIGURATION) request, and the kernel logs 'unable to read config index 0 descriptor/start: -71'. The device then falls back to a secondary Android HID mode (with a different VID:PID), losing XInput functionality including rumble support. The failure reproduces across multiple machines, host controller types, and kernel versions including current mainline and LTS. The device enumerates correctly and remains in XInput mode under Windows. Notably, the device enumerates correctly in Android mode when the same 9-byte request is issued for that mode's configuration descriptor, confirming the firmware bug is specific to the XInput mode. usbmon traces from Linux and Wireshark/USBPcap traces from Windows are identical up to the point of failure, with no visible protocol-level difference explaining the divergence. The root cause was identified when Michal Pecio discovered via a QEMU bus-level capture that Windows does not use wLength=9 for the initial config descriptor request; it uses wLength=255. Alan Stern subsequently confirmed this with a bus analyzer on a different USB 2.0 device, and Michal verified the behavior goes back to Windows 95 OSR2.1. So, add a new quirk flag USB_QUIRK_WINDOWS_CONFIG_REQ_SIZE which causes usb_get_configuration() to issue a 255 byte sized configuration request instead of USB_DT_CONFIG_SIZE (9) for the initial GET_DESCRIPTOR(CONFIGURATION) request, mimicking long-standing Windows behavior. This patch intentionally does not add any new VID:PID entries using this quirk. Some affected Xbox 360-compatible controllers spoof Microsoft's VID:PID, while genuine Microsoft controllers already enumerate correctly and do not require this quirk. Other affected clone devices use their own VID:PID pairs and can be added individually as they are identified. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Suggested-by: Michal Pecio <michal.pecio@gmail.com> Closes: https://lore.kernel.org/linux-usb/CAFgddh+JWdT4LLwMc5qjM8q_pBu-fRo2qADR5ovAKoGHWMQrRw@mail.gmail.com/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable <stable@kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Nikhil Solanke <nikhilsolanke5@gmail.com> Link: https://patch.msgid.link/20260728195158.65162-2-nikhilsolanke5@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-03usb: atm: cxacru: properly kill rcv_urb on error in cxacru_cm()Aleksandr Nogikh1-0/+2
If cxacru_cm() encounters an error while submitting or waiting for snd_urb, it aborts and returns the error without killing the already submitted rcv_urb. This leaves the rcv_urb active. When this happens during initialization (e.g., in cxacru_atm_start()), the driver may ignore the error and proceed to call cxacru_poll_status(), which invokes cxacru_cm() again. Attempting to submit the still-active rcv_urb triggers a warning in usb_submit_urb(): cxacru 1-1:1.0: send of cm 0x84 failed (-104) ATM dev 0: cxacru_atm_start: CHIP_ADSL_LINE_START returned -104 ------------[ cut here ]------------ URB ffff88812658d200 submitted while active WARNING: drivers/usb/core/urb.c:379 at usb_submit_urb+0x79/0x18b0 drivers/usb/core/urb.c:379 ... Call Trace: <TASK> cxacru_cm+0x21a/0xf10 drivers/usb/atm/cxacru.c:631 cxacru_cm_get_array drivers/usb/atm/cxacru.c:722 [inline] cxacru_poll_status+0x178/0x1110 drivers/usb/atm/cxacru.c:828 cxacru_atm_start+0x185/0x360 drivers/usb/atm/cxacru.c:814 usbatm_atm_init+0x144/0x3a0 drivers/usb/atm/usbatm.c:927 usbatm_usb_probe+0x15cb/0x1db0 drivers/usb/atm/usbatm.c:1178 cxacru_usb_probe+0x17f/0x220 drivers/usb/atm/cxacru.c:1370 ... To fix this, ensure that rcv_urb is properly killed if cxacru_cm() aborts early. We can safely call usb_kill_urb() on rcv_urb in the error path, as it is safe to call even if the URB is not active (e.g., if it failed to submit in the first place, or if it already completed). Fixes: 1b0e61465234 ("[PATCH] USB ATM: driver for the Conexant AccessRunner chipset cxacru") Cc: stable <stable@kernel.org> Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+c9dff578c3a41775176a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c9dff578c3a41775176a Link: https://syzkaller.appspot.com/ai_job?id=75fec6f2-c8a6-43b1-b184-4d26baba86cc Signed-off-by: Aleksandr Nogikh <nogikh@google.com> Link: https://patch.msgid.link/91edfa4c-a63d-400c-9f00-31f3e1f98c00@mail.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-03usb: misc: usbio: check ibuf_len against rxbuf_len in bulk msgJiangshan Yi1-1/+1
ibuf_len is the bulk IN (receive) buffer size, but the EMSGSIZE check in usbio_bulk_msg() compares it against txbuf_len — the bulk OUT endpoint size. Both are taken independently from different endpoints in usbio_probe(), so the check is wrong when they differ. Use rxbuf_len for the IN direction. This matches the buffer that actually holds the response data. Fixes: 121a0f839dbb ("usb: misc: Add Intel USBIO bridge driver") Cc: stable <stable@kernel.org> Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn> Tested-by: Antti Laakso <antti.laakso@linux.intel.com> Link: https://patch.msgid.link/20260722101810.458634-1-yijiangshan@kylinos.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-03usb: gadget: f_ncm: Use unsigned int for ndp_indexSonali Pradhan1-1/+1
The variable ndp_index is declared as a signed integer, but it stores the return value of get_ncm(), which is unsigned. A malicious host can supply a large offset that overflows the signed ndp_index, making it negative. Because ndp_index is compared against unsigned bounds, this negative value bypasses sanity checks and leads to an out-of-bounds read when calculating the address of the NDP block (ntb_ptr + ndp_index). Fix this by changing ndp_index to unsigned int to ensure consistent unsigned comparisons throughout the function. Fixes: 370af734dfaf ("usb: gadget: NCM: RX function support multiple NDPs") Cc: stable <stable@kernel.org> Signed-off-by: Sonali Pradhan <sonalipradhan@google.com> Link: https://patch.msgid.link/20260720165654.2224591-1-sonalipradhan@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-03usb: cdnsp: fix incorrect endian conversions for APB timeout registerPawel Laszczak1-2/+2
readl() already returns a CPU-endian value. Passing its return value to le32_to_cpu() is therefore redundant and causes an incorrect double byte swap on big-endian systems. Similarly, writel() expects a CPU-endian value, so passing the result of cpu_to_le32() is incorrect. Remove the unnecessary conversions and operate on the MMIO register value as a CPU-endian u32. Fixes: 241e2ce88e5a ("usb: cdnsp: Fix issue with resuming from L1") Suggested-by: Arnd Bergmann <arnd@arndb.de> Cc: stable <stable@kernel.org> Signed-off-by: Pawel Laszczak <pawell@cadence.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260720-endian-fix-v1-v1-1-b5681fa1ea9f@cadence.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-03USB: serial: pl2303: add support for PL256X multi-port devicesCharles Yeh2-8/+102
Prolific PL256X devices are multi-port USB-to-UART controllers, including the PL2533, PL2543 and PL2565 variants. These devices use vendor requests that differ from those used by the existing TYPE_HX and TYPE_HXN devices. They also require a separate UART reset request and use a port-specific register for configuring flow control. Add a new TYPE_MP device type and select the appropriate vendor requests, reset operation and flow-control register for PL256X devices. Store the USB interface number so that requests can be directed to the corresponding UART port. Detect the supported PL256X variants using bcdDevice before issuing any legacy vendor requests, as PL256X devices do not accept those requests. PL256X devices support baud rates up to 24 Mbps and do not use divisor encoding. Signed-off-by: Charles Yeh <charlesyeh522@gmail.com> Link: https://lore.kernel.org/all/CAAZvQQ6O4p35Xs2hVYaoJxD4D7U0YonsdweuPh6W8RQVhvoUNw@mail.gmail.com/ Signed-off-by: Johan Hovold <johan@kernel.org>
2026-08-03USB: serial: digi_acceleport: add port lock nesting annotationJohan Hovold1-2/+7
The driver takes the driver port lock of both the OOB port and the port itself when setting the modem control signals, which confuses lockdep. Mark the OOB port lock as belonging to a separate subclass to suppress false positive lockdep deadlock warnings. Reported-by: syzbot+2051460e19471eeb42c3@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/6a6cd832.1aa927e4.17d4bf.0007.GAE@google.com/ Signed-off-by: Johan Hovold <johan@kernel.org>
2026-07-31USB: serial: option: fix slab OOB read in interrupt URB callbackJiale Yao1-3/+17
The interrupt URB buffer is allocated in setup_port_interrupt_in() based on the endpoint's wMaxPacketSize: buffer_size = usb_endpoint_maxp(epd); port->interrupt_in_buffer = kmalloc(buffer_size, GFP_KERNEL); When a USB device declares wMaxPacketSize = 8 on its interrupt IN endpoint, the buffer is allocated from kmalloc-8 cache (exactly 8 bytes). If the device sends a short packet (actual_length < wMaxPacketSize), the URB completes with status == 0 and the callback proceeds to read: data[sizeof(struct usb_ctrlrequest)] which evaluates to data[8], accessing 1 byte beyond the allocated 8-byte buffer. This results in a slab out-of-bounds read. Fix this by adding the missing bounds check: first verify that the actual length is large enough to contain the struct usb_ctrlrequest header before accessing req_pkt->bRequestType and req_pkt->bRequest, and then verify that there is an additional byte for the modem signal state before reading data[sizeof(struct usb_ctrlrequest)] inside the conditional. Use sizeof(*req_pkt) instead of sizeof(struct usb_ctrlrequest) for consistency. Assisted-by: Claude:deepseek-v4-pro Signed-off-by: Jiale Yao <yaojiale02@163.com> Fixes: 58cfe9113e48 ("[PATCH] USB: add Option Card driver") Cc: stable@vger.kernel.org # v2.6.12 [ johan: use dev_err(); split signals declaration and initialisation ] Signed-off-by: Johan Hovold <johan@kernel.org>
2026-07-29powerpc: Move CONFIG_QE_GPIO to SoCChristophe Leroy (CS GROUP)1-0/+1
Commit 7aa1aa6ecec2 ("QE: Move QE from arch/powerpc to drivers/soc") moved QE into drivers/soc including gpio.c but left CONFIG_QE_GPIO in powerpc's Kconfig. Move it to SoC as well as it is the only place it is used: drivers/soc/fsl/qe/Makefile:obj-$(CONFIG_QE_GPIO) += gpio.o qe_ports_ic.o include/soc/fsl/qe/qe.h:#ifdef CONFIG_QE_GPIO include/soc/fsl/qe/qe.h:#endif /* CONFIG_QE_GPIO */ There is also a dependency in USB subsystem for CONFIG_USB_FHCI_HCD: drivers/usb/host/Kconfig: depends on QE_GPIO && QUICC_ENGINE Because that USB driver selects CONFIG_FSL_GTM which is specific to powerpc, it has to depend on CONFIG_PPC. Acked-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://lore.kernel.org/r/9a7131d15a94e2017877e628f0e97f9aa2e0aae9.1785140877.git.chleroy@kernel.org Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
2026-07-27Merge 7.2-rc5 into usb-nextGreg Kroah-Hartman31-212/+599
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-24Merge tag 'usb-serial-7.2-rc4' of ↵Greg Kroah-Hartman7-10/+58
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB serial fixes for 7.2-rc4 Here are some fixes for 7.2: - fix data loss on keyspan_pda throttle - fix memory corruption with malicious edgeport devices - fix memory corruption with corrupt io_ti firmware - fix OOB read with corrupt mxuport firmware Included are also some new ftdi and modem device ids. All have been in linux-next with no reported issues. * tag 'usb-serial-7.2-rc4' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: io_edgeport: cap received transmit credits USB: serial: option: add TDTECH MT5710-CN USB: serial: io_ti: reject oversized boot-mode firmware USB: serial: mxuport: validate firmware header size USB: serial: ftdi_sio: add support for E+H FXA291 USB: serial: keyspan_pda: fix data loss on receive throttling
2026-07-23usb: typec: ucsi: Correct teardown ordering in ucsi_init() error pathAndrei Kuchynski1-2/+2
The commit 7aa7d4bf9d3f ("usb: typec: ucsi: Fix race condition and ordering in port unregistration") consolidated port teardown into the ucsi_unregister_port() helper. However, it introduced an ordering problem in the ucsi_init() error path. Fix this by ensuring ucsi_unregister_port() is called before we unregister their corresponding lockdep keys. Cc: stable@vger.kernel.org Fixes: 7aa7d4bf9d3f ("usb: typec: ucsi: Fix race condition and ordering in port unregistration") Reported-by: "Borah, Chaitanya Kumar" <chaitanya.kumar.borah@intel.com> Closes: https://lore.kernel.org/all/22064276-6c56-411a-9f20-6917ceeb865f@intel.com/ Signed-off-by: Andrei Kuchynski <akuchynski@chromium.org> Tested-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260717104614.325250-1-akuchynski@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-23usb: core: reformat error handling and messagesGriffin Kroah-Hartman1-6/+6
Rearrange the error handling changes in the previous patch, in both hub_ext_port_status() and hub_hub_status(), in respect to maintainer feedback. Additionally, change the two usages of dev_err() in these functions to dev_dbg(), and reformat the error messages to be more accurate. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Griffin Kroah-Hartman <griffin@kroah.com> Link: https://patch.msgid.link/20260722-usb_core_patches_2-v3-2-87622252bfdd@kroah.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-23usb: core: Strengthen error handling in hub_hub_status()Griffin Kroah-Hartman1-1/+3
Add additional error handling after the call to get_hub_status() in hub_hub_status(). get_hub_status() uses usb_control_msg() which does not verify that the message is the correct length, substituting it for usb_control_msg_recv() would also solve this issue but increase memory allocations. Instead, error handling is copied from the method used in hub_ext_port_status(), which shares the same flow of logic as hub_hub_status(). Assisted-by: gkh_clanker_t1000 Signed-off-by: Griffin Kroah-Hartman <griffin@kroah.com> Link: https://patch.msgid.link/20260722-usb_core_patches_2-v3-1-87622252bfdd@kroah.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-23usb: gadget: f_mass_storage: Remove obsolete version logFabio Estevam1-3/+0
The mass-storage function prints the following message whenever a function instance is allocated: Mass Storage Function, version: 2009/09/11 The hard-coded date does not identify the running kernel or provide useful diagnostic information. Remove the message and the unused version definition. Signed-off-by: Fabio Estevam <festevam@gmail.com> Link: https://patch.msgid.link/20260721020957.81956-1-festevam@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-23usb: typec: tcpm: implement retry mechanism for Discover Identity VDMsRD Babiera1-142/+259
The current mechanism for sending Discover Identity in the ready state presents a flaw where tcpm_queue_vdm can collide with non interruptible AMSes such as GET_SINK_CAP or VCONN_SWAP. vdm_run_state_machine will hit the VDM_STATE_BUSY state, and Discover SVIDs or Discover Modes will not retry. This patch introduces a state machine under the enum vdm_discovery_states. The tcpm_port field vdm_discovery_state tracks which step of the Discover Identity process has been completed. The current TCPM implementation utilizes the send_discover and send_discover_prime booleans to queue Discover Identity in the aforementioned collision case. These booleans are removed in place of vdm_discovery_state and send_discover_work is replaced by vdm_discovery_work, which runs unconditionally in the ready state. When the Discovery process is complete, the port will move to the VDM_DISCOVERY_COMPLETE state and vdm_discovery_work becomes a no-op. When there are still Discovery VDMs to be sent, vdm_discovery_work will continue based on the last received response from the port partner or cable. Signed-off-by: RD Babiera <rdbabiera@google.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Badhri Jagan Sridharan <badhri@google.com> Link: https://patch.msgid.link/20260717232612.3671978-2-rdbabiera@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-22USB: serial: io_edgeport: cap received transmit creditsSunho Park1-1/+2
The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Sunho Park <shpark061104@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2026-07-21USB: serial: option: add TDTECH MT5710-CNChukun Pan1-0/+1
Add support for the TDTECH MT5710-CN (5G redcap) module based on the Huawei HiSilicon Balong chip. T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=3466 ProdID=3301 Rev=ff.ff S: Manufacturer=TD Tech Ltd. S: Product=TDTECH MT571X S: SerialNumber=0123456789ABCDEF C:* #Ifs= 6 Cfg#= 1 Atr=c0 MxPwr= 0mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0d Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0d Prot=00 Driver=cdc_ncm E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=13 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=12 Driver=option E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=1c Driver=option E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=14 Driver=option E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Interface: ECM / NCM + DIAG + AT + SERIAL + GPS Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>