kernel/drivers/usb/host/xhci.c, branch linux-rolling-lts

usb: xhci: Fix memory leak in xhci_disable_slot()

2026-03-19T15:08:25Z

commit c1c8550e70401159184130a1afc6261db01fc0ce upstream. xhci_alloc_command() allocates a command structure and, when the second argument is true, also allocates a completion structure. Currently, the error handling path in xhci_disable_slot() only frees the command structure using kfree(), causing the completion structure to leak. Use xhci_free_command() instead of kfree(). xhci_free_command() correctly frees both the command structure and the associated completion structure. Since the command structure is allocated with zero-initialization, command->in_ctx is NULL and will not be erroneously freed by xhci_free_command(). This bug was found using an experimental static analysis tool we are developing. The tool is based on the LLVM framework and is specifically designed to detect memory management issues. It is currently under active development and not yet publicly available, but we plan to open-source it after our research is published. The bug was originally detected on v6.13-rc1 using our static analysis tool, and we have verified that the issue persists in the latest mainline kernel. We performed build testing on x86_64 with allyesconfig using GCC=11.4.0. Since triggering these error paths in xhci_disable_slot() requires specific hardware conditions or abnormal state, we were unable to construct a test case to reliably trigger these specific error paths at runtime. Fixes: 7faac1953ed1 ("xhci: avoid race between disable slot command and host runtime suspend") CC: stable@vger.kernel.org Signed-off-by: Zilin Guan Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20260304223639.3882398-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

xhci: sideband: don't dereference freed ring when removing sideband endpoint

2026-01-23T10:21:26Z

commit dd83dc1249737b837ac5d57c81f2b0977c613d9f upstream. xhci_sideband_remove_endpoint() incorrecly assumes that the endpoint is running and has a valid transfer ring. Lianqin reported a crash during suspend/wake-up stress testing, and found the cause to be dereferencing a non-existing transfer ring 'ep->ring' during xhci_sideband_remove_endpoint(). The endpoint and its ring may be in unknown state if this function is called after xHCI was reinitialized in resume (lost power), or if device is being re-enumerated, disconnected or endpoint already dropped. Fix this by both removing unnecessary ring access, and by checking ep->ring exists before dereferencing it. Also make sure endpoint is running before attempting to stop it. Remove the xhci_initialize_ring_info() call during sideband endpoint removal as is it only initializes ring structure enqueue, dequeue and cycle state values to their starting values without changing actual hardware enqueue, dequeue and cycle state. Leaving them out of sync is worse than leaving it as it is. The endpoint will get freed in after this in most usecases. If the (audio) class driver want's to reuse the endpoint after offload then it is up to the class driver to ensure endpoint is properly set up. Reported-by: 胡连勤 Closes: https://lore.kernel.org/linux-usb/TYUPR06MB6217B105B059A7730C4F6EC8D2B9A@TYUPR06MB6217.apcprd06.prod.outlook.com/ Tested-by: 胡连勤 Fixes: de66754e9f80 ("xhci: sideband: add initial api to register a secondary interrupter entity") Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20260115233758.364097-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

xhci: fix stale flag preventig URBs after link state error is cleared

2025-11-09T01:54:44Z

A usb device caught behind a link in ss.Inactive error state needs to be reset to recover. A VDEV_PORT_ERROR flag is used to track this state, preventing new transfers from being queued until error is cleared. This flag may be left uncleared if link goes to error state between two resets, and print the following message: "xhci_hcd 0000:00:14.0: Can't queue urb, port error, link inactive" Fix setting and clearing the flag. The flag is cleared after hub driver has successfully reset the device when hcd->reset_device is called. xhci-hcd issues an internal "reset device" command in this callback, and clear all flags once the command completes successfully. This command may complete with a context state error if slot was recently reset and is already in the defauilt state. This is treated as a success but flag was left uncleared. The link state field is also unreliable if port is currently in reset, so don't set the flag in active reset cases. Also clear the flag immediately when link is no longer in ss.Inactive state and port event handler detects a completed reset. This issue was discovered while debugging kernel bugzilla issue 220491. It is likely one small part of the problem, causing some of the failures, but root cause remains unknown Link: https://bugzilla.kernel.org/show_bug.cgi?id=220491 Fixes: b8c3b718087b ("usb: xhci: Don't try to recover an endpoint if port is in error state.") Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251107162819.1362579-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

Merge patch series "eUSB2 Double Isochronous IN Bandwidth support"

2025-09-06T13:25:08Z

Sakari Ailus says: This series enables support for eUSB2 Double Isochronous IN Bandwidth UVC devices specified in 'USB 2.0 Double Isochronous IN Bandwidth' ECN. In short, it adds support for new integrated USB2 webcams that can send twice the data compared to conventional USB2 webcams. These devices are identified by the device descriptor bcdUSB 0x0220 value. They have an additional eUSB2 Isochronous Endpoint Companion Descriptor, and a zero max packet size in regular isoc endpoint descriptor. Support for parsing that new descriptor was added in commit c749f058b437 ("USB: core: Add eUSB2 descriptor and parsing in USB core") This series adds support to UVC, USB core, and xHCI to identify eUSB2 double isoc devices, and allow and set proper max packet, iso frame desc sizes, bytes per interval, and other values in URBs and xHCI endpoint contexts needed to support the double data rates for eUSB2 double isoc devices. since v4: https://lore.kernel.org/linux-usb/20250812132445.3185026-1-sakari.ailus@linux.intel.com - New patch: use le16_to_cpu() to access endpoint descriptor's wMaxPacketSize field, which is an __le16. This isn't a bugfix as the value was compared to 0. - New patch: add USB device speed check for eUSB2 isochronous endpoint companion parsing. The check is then removed from sites checking the existence of the companion (through companion's bDescriptorType field, which is non-zero for valid descriptors). - New patch: do not parse eUSB2 isoc double BW companion descriptor on interrupt or OUT endpoints. It is not supposed to be found there, according to the ECN. - Rename usb_endpoint_max_isoc_bpi() as usb_endpoint_max_periodic_payload() and move it right after usb_maxpacket(). - Fixed @ep reference in kernel-doc documentation for usb_endpoint_max_periodic_payload(). - In usb_endpoint_max_periodic_payload(), call struct usb_device pointer argument "udev" instead of "dev", to align with naming elsewhere. - Add support for interrupt endpoints in usb_endpoint_max_periodic_payload(); eUSB2 double isoc BW is still limited to isochronous endpoints though. - In usb_endpoint_max_periodic_payload(), remove the separate case for USB_SPEED_HIGH as the check is already done in parsing the eUSB isoc double BW companion, which is checked for. - New patch: use usb_endpoint_max_periodic_payload() in xHCI driver, replacing xhci_get_max_esit_payload(). - Check non-zero bDescriptorType field of ep->eusb2_isoc_ep_comp instead of dwBytesPerInterval value exceeding 3072, where xhci_eusb2_is_isoc_bw_double() was used. This aligns the checks of eUSB2 isochronous double bandwidth support for an endpoint. - New patch: introduce usb_endpoint_is_hs_isoc_double() to figure out whether an endpoint uses isochronous double bandwidth and use the function in the xHCI driver and the usb core. xhci_eusb2_is_isoc_bw_double() is dropped, as well as the MAX_ISOC_XFER_SIZE_HS macro. usb_endpoint_is_hs_isoc_double() also includes check for bcdUSB == 0x220, to anticipate adding support for eUSB2V2. - Merge condition for checking eUSB2 isoc double bw support for xHCI/endpoint in xhci_get_endpoint_mult(). - Improve comment regarding maximum packet size bits 12:11 in xhci_get_endpoint_max_burst(). - Aligned subject prefixes with the recent patches to the same files. since v3: https://lore.kernel.org/linux-usb/20250807055355.1257029-1-sakari.ailus@linux.intel.com/ - Use spaces in aligning macro body for HCC2_EUSB2_DIC() (1st patch). - Move usb_endpoint_max_isoc_bpi() to drivers/usb/core/usb.c (3rd patch). since v2: https://lore.kernel.org/linux-usb/20250711083413.1552423-1-sakari.ailus@linux.intel.com - Use ep->eusb2_isoc_ep_comp.bDescriptorType to determined whether the eUSB2 isochronous endpoint companion descriptor exists. - Clean up eUSB2 double isoc bw maxp calculation. - Drop le16_to_cpu(udev->descriptor.bcdUSB) == 0x220 check from xhci_eusb2_is_isoc_bw_double() -- it's redundant as ep->eusb2_isoc_ep_comp.dwBytesPerInterval will be zero otherwise. - Add kernel-doc documentation for usb_endpoint_max_isoc_bpi(). - Check the endpoint has IN direction in usb_endpoint_max_isoc_bpi() and usb_submit_urb() as a condition for eUSB2 isoc double bw. since v1: https://lore.kernel.org/linux-usb/20250616093730.2569328-2-mathias.nyman@linux.intel.com - Introduce uvc_endpoint_max_isoc_bpi() to obtain maximum bytes per interval value for an endpoint, in a new patch (3rd). This code has been slightly reworked from the instance in the UVC driver, including support for SuperSpeedPlus Isochronous Endpoint Companion. - Use usb_endpoint_max_isoc_bpi() in the UVC driver instead of open-coding eUSB2 support there, also drop now-redundant uvc_endpoint_max_bpi(). - Use u32 for maximum bpi and related information in the UVC driver -- the value could be larger than a 16-bit type can hold. - Assume max in usb_submit_urb() is a natural number as usb_endpoint_maxp() returns only natural numbers (2nd patch). Link: https://lore.kernel.org/r/20250820143824.551777-1-sakari.ailus@linux.intel.com Cc: Sakari Ailus Signed-off-by: Greg Kroah-Hartman

usb: xhci: Add host support for eUSB2 double isochronous bandwidth devices

2025-09-06T13:25:05Z

Detect eUSB2 double isoc bw capable hosts and devices, and set the proper xhci endpoint context values such as 'Mult', 'Max Burst Size', and 'Max ESIT Payload' to enable the double isochronous bandwidth endpoints. Intel xHC uses the endpoint context 'Mult' field for eUSB2 isoc endpoints even if hosts supporting Large ESIT Payload Capability should normally ignore the mult field. Signed-off-by: Rai, Amardeep Co-developed-by: Kannappan R Signed-off-by: Kannappan R Reviewed-by: Sakari Ailus Co-developed-by: Mathias Nyman Signed-off-by: Mathias Nyman Co-developed-by: Sakari Ailus Signed-off-by: Sakari Ailus Acked-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20250820143824.551777-8-sakari.ailus@linux.intel.com

usb: xhci: fix host not responding after suspend and resume

2025-08-19T14:12:13Z

Partially revert commit e1db856bd288 ("usb: xhci: remove '0' write to write-1-to-clear register") because the patch cleared the Interrupt Pending bit during interrupt enabling and disabling. The Interrupt Pending bit should only be cleared when the driver has handled the interrupt. Ideally, all interrupts should be handled before disabling the interrupt; consequently, no interrupt should be pending when enabling the interrupt. For this reason, keep the debug message informing if an interrupt is still pending when an interrupt is disabled. Because the Interrupt Pending bit is write-1-to-clear, writing '0' to it ensures that the state does not change. Link: https://lore.kernel.org/linux-usb/20250818231103.672ec7ed@foxbook Fixes: e1db856bd288 ("usb: xhci: remove '0' write to write-1-to-clear register") Closes: https://bbs.archlinux.org/viewtopic.php?id=307641 cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250819125844.2042452-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

usb: xhci: Fix slot_id resource race conflict

2025-08-19T14:12:13Z

xHC controller may immediately reuse a slot_id after it's disabled, giving it to a new enumerating device before the xhci driver freed all resources related to the disabled device. In such a scenario, device-A with slot_id equal to 1 is disconnecting while device-B is enumerating, device-B will fail to enumerate in the follow sequence. 1.[device-A] send disable slot command 2.[device-B] send enable slot command 3.[device-A] disable slot command completed and wakeup waiting thread 4.[device-B] enable slot command completed with slot_id equal to 1 and wakeup waiting thread 5.[device-B] driver checks that slot_id is still in use (by device-A) in xhci_alloc_virt_device, and fail to enumerate due to this conflict 6.[device-A] xhci->devs[slot_id] set to NULL in xhci_free_virt_device To fix driver's slot_id resources conflict, clear xhci->devs[slot_id] and xhci->dcbba->dev_context_ptrs[slot_id] pointers in the interrupt context when disable slot command completes successfully. Simultaneously, adjust function xhci_free_virt_device to accurately handle device release. [minor smatch warning and commit message fix -Mathias] Cc: stable@vger.kernel.org Fixes: 7faac1953ed1 ("xhci: avoid race between disable slot command and host runtime suspend") Signed-off-by: Weitao Wang Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250819125844.2042452-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

usb: xhci: Avoid showing warnings for dying controller

2025-07-17T08:53:04Z

When a USB4 dock is unplugged from a system it won't respond to ring events. The PCI core handles the surprise removal event and notifies all PCI drivers. The XHCI PCI driver sets a flag that the device is being removed, and when the device stops responding a flag is also added to indicate it's dying. When that flag is set don't bother to show warnings about a missing controller. Signed-off-by: Mario Limonciello Signed-off-by: Mathias Nyman Acked-by: Mathias Nyman Link: https://lore.kernel.org/r/20250717073107.488599-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

Revert "usb: xhci: Implement xhci_handshake_check_state() helper"

2025-06-19T10:41:35Z

This reverts commit 6ccb83d6c4972ebe6ae49de5eba051de3638362c. Commit 6ccb83d6c497 ("usb: xhci: Implement xhci_handshake_check_state() helper") was introduced to workaround watchdog timeout issues on some platforms, allowing xhci_reset() to bail out early without waiting for the reset to complete. Skipping the xhci handshake during a reset is a dangerous move. The xhci specification explicitly states that certain registers cannot be accessed during reset in section 5.4.1 USB Command Register (USBCMD), Host Controller Reset (HCRST) field: "This bit is cleared to '0' by the Host Controller when the reset process is complete. Software cannot terminate the reset process early by writinga '0' to this bit and shall not write any xHC Operational or Runtime registers until while HCRST is '1'." This behavior causes a regression on SNPS DWC3 USB controller with dual-role capability. When the DWC3 controller exits host mode and removes xhci while a reset is still in progress, and then tries to configure its hardware for device mode, the ongoing reset leads to register access issues; specifically, all register reads returns 0. These issues extend beyond the xhci register space (which is expected during a reset) and affect the entire DWC3 IP block, causing the DWC3 device mode to malfunction. Cc: stable Fixes: 6ccb83d6c497 ("usb: xhci: Implement xhci_handshake_check_state() helper") Signed-off-by: Roy Luo Link: https://lore.kernel.org/r/20250522190912.457583-3-royluo@google.com Signed-off-by: Greg Kroah-Hartman

usb: xhci: Skip xhci_reset in xhci_resume if xhci is being removed

2025-06-19T10:41:32Z

xhci_reset() currently returns -ENODEV if XHCI_STATE_REMOVING is set, without completing the xhci handshake, unless the reset completes exceptionally quickly. This behavior causes a regression on Synopsys DWC3 USB controllers with dual-role capabilities. Specifically, when a DWC3 controller exits host mode and removes xhci while a reset is still in progress, and then attempts to configure its hardware for device mode, the ongoing, incomplete reset leads to critical register access issues. All register reads return zero, not just within the xHCI register space (which might be expected during a reset), but across the entire DWC3 IP block. This patch addresses the issue by preventing xhci_reset() from being called in xhci_resume() and bailing out early in the reinit flow when XHCI_STATE_REMOVING is set. Cc: stable Fixes: 6ccb83d6c497 ("usb: xhci: Implement xhci_handshake_check_state() helper") Suggested-by: Mathias Nyman Signed-off-by: Roy Luo Link: https://lore.kernel.org/r/20250522190912.457583-2-royluo@google.com Signed-off-by: Greg Kroah-Hartman