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

usb: xhci: Fix memory leak in xhci_disable_slot()

2026-03-19T15:15:03Z

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-16T11:19:37Z

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

Merge tag 'usb-6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb

2025-12-07T02:42:12Z

Pull USB/Thunderbolt updates from Greg KH: "Here is the big set of USB and Thunderbolt driver updates for 6.19-rc1. Nothing major here, just lots of tiny updates for most of the common USB drivers. Included in here are: - more xhci driver updates and fixes - Thunderbolt driver cleanups - usb serial driver updates - typec driver updates - USB tracepoint additions - dwc3 driver updates, including support for Apple hardware - lots of other smaller driver updates and cleanups All of these have been in linux-next for a while with no reported issues" * tag 'usb-6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (161 commits) usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt USB: serial: option: move Telit 0x10c7 composition in the right place USB: serial: option: add Telit Cinterion FE910C04 new compositions usb: typec: ucsi: fix use-after-free caused by uec->work usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe() usb: dwc3: core: Remove redundant comment in core init usb: phy: Initialize struct usb_phy list_head USB: serial: option: add Foxconn T99W760 usb: usb-storage: No additional quirks need to be added to the EL-R12 optical drive. usb: typec: hd3ss3220: Enable VBUS based on ID pin state dt-bindings: usb: ti,hd3ss3220: Add support for VBUS based on ID state usb: typec: anx7411: add WQ_PERCPU to alloc_workqueue users USB: add WQ_PERCPU to alloc_workqueue users dt-bindings: usb: dwc3-xilinx: Describe the reset constraint for the versal platform drivers/usb/storage: use min() instead of min_t() usb: raw-gadget: cap raw_io transfer length to KMALLOC_MAX_SIZE usb: ohci-da8xx: remove unused platform data usb: gadget: functionfs: use dma_buf_unmap_attachment_unlocked() helper usb: uas: reduce time under spinlock usb: dwc3: eic7700: Add EIC7700 USB driver ...

usb: xhci: standardize single bit-field macros

2025-11-21T13:53:01Z

Convert single bit-field macros to simple masks. The change makes the masks more universal. Multi bit-field macros are changed in the next commit. After both changes, all masks in xhci-caps.h will follow the same format. I plan to introduce this change to all xhci macros. Bit shift operations on a 32-bit signed can be problematic on some architectures. Instead use BIT() macro, which returns a 64-bit unsigned value. This ensures that the shift operation is performed on an unsigned type, which is safer and more portable across different architectures. Using unsigned integers for bit shifts avoids issues related to sign bits and ensures consistent behavior. Switch from 32-bit to 64-bit? As far as I am aware, this does not cause any issues. Performing bitwise operations between 32 and 64 bit values, the smaller operand is promoted to match the size of the larger one, resulting in a 64-bit operation. This promotion extends the 32-bit value to 64 bits, by zero-padding (for unsigned). Will the change to 64-bit slow down the xhci driver? On a 64-bit architecture - No. On a 32-bit architecture, yes? but in my opinion the performance decrease does not outweigh the readability and other benefits of using BIT() macro. Why not use FIELD_GET() and FIELD_PREP()? While they can be used for single bit macros, I prefer to use simple bitwise operation directly. Because, it takes less space, is less overhead and is as clear as if using FIELD_GET() and FIELD_PREP(). Why not use test_bit() macro? Same reason as with FIELD_GET() and FIELD_PREP(). Suggested-by: Sakari Ailus Reviewed-by: Sakari Ailus Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251119142417.2820519-23-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

usb: xhci: limit number of interrupts to 128

2025-11-21T13:53:00Z

The xHCI driver defines only 128 interrupter register slots, yet allows up to 2047 interrupters. According to the xHCI specification, the maximum valid number of interrupters is 1024. These mismatches can lead to out-of-range accesses and excessive memory use. The Number of Interrupters (MaxIntrs) field occupies bits 18:8 of the HCSPARAMS1 register, which can yield a value up to 2047, although the specification limits it to 1024. Cap the value using the 'MAX_HC_INTRS' macro. Set 'xhci->max_intrs' to the minimum of the value reported by the HCSPARAMS1 register and 'MAX_HC_INTRS'. The interrupter register slot array is defined for 1024 entries, serving only as a structural template and not increasing memory usage. Although the xHCI specification allows up to 1024 interrupters, raising 'MAX_HC_INTRS' above 128 provides no practical benefit. The driver only uses the primary interrupter (0), and secondary interrupters (1+) are rarely, if ever, used in practice. No reports exist of usage beyond 128. Therefore, I have limited it to 128. Summary: * Interrupter allocations are now limited to 128 from 2047. * Interrupter Register template slots are set to 1024 from 128. * Macro 'MAX_HC_INTRS' can be modified to set the interrupter limit. ==== Detailed interrupter explanation ==== There are two relevant components: Interrupter array: This holds the software interrupter structures and is allocated by the xhci driver. The number of interrupters allocated is determined by the HCSPARAMS1 register field, which specifies the supported interrupter count. Interrupter register slots: This is a template struct used to access the hardware's runtime registers. It is not allocated by the driver, the hardware defines and owns this memory region, and the driver only maps it for MMIO access. Each entry in the interrupter array points to its corresponding interrupter register slot in the hardware region once that interrupter is enabled. Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251119142417.2820519-18-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

usb: xhci: limit number of ports to 127

2025-11-21T13:53:00Z

The xHCI driver allocates various port-related structures based on the maximum number of ports reported by the controller. The Number of Ports (MaxPorts) field occupies bits 31:24 of the HCSPARAMS1 register and can represent values up to 255. However, the 'HCS_MAX_PORTS()' macro currently reads bits 30:24, effectively limiting the maximum to 127. Fixing the macro increases the reported port limit to 255, which in turn increases memory usage regardless of how many ports are actually used. To maintain compatibility and control memory consumption, set 'xhci->max_ports' to the minimum of the value read from 'HCS_MAX_PORTS()' and 127 (MAX_HC_PORTS). This preserves the existing limit while making the restriction explicit and easier to adjust in the future. Summary: * Port allocations are now limited to 127. * HC max ports macro now correctly reads the MaxPorts value. * Macro 'MAX_HC_PORTS' can be modified to set the port limit. Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251119142417.2820519-17-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

usb: xhci: simplify handling of Structural Parameters 1 values

2025-11-21T13:53:00Z

The 32-bit read-only HCSPARAMS1 register contains the following fields: Bits 7:0 - Number of Device Slots (MaxSlots) Bits 18:8 - Number of Interrupters (MaxIntrs) Bits 23:19 - Reserved Bits 31:24 - Number of Ports (MaxPorts) Since the register value is constant for the lifetime of the controller, it is cached in 'xhci->hcs_params1'. However, platform drivers may override the number of interrupters through a separate variable, 'xhci->max_interrupters', leaving only the maximum slots and ports values still derived from the cached register. To simplify the code and improve readability, replace 'xhci->hcs_params1' with two dedicated 'u8' fields: 'xhci->max_slots' and 'xhci->max_ports'. These values are initialized once and used directly instead of calling 'HCS_MAX_SLOTS()' and 'HCS_MAX_PORTS()' macros. This change reduces code clutter without increasing memory usage. Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251119142417.2820519-16-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

usb: xhci: use cached HCSPARAMS1 value

2025-11-21T13:53:00Z

The Structural Parameters 1 (HCSPARAMS1) register is read and cached in 'xhci->hcs_params1' during host controller initialization. Since this register is read-only and its value remains constant for the lifetime of the controller, re-reading it later is unnecessary. Replace subsequent register reads with the cached 'xhci->hcs_params1' value to avoid redundant MMIO access. Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251119142417.2820519-15-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

usb: xhci: remove unused trace operation and argument

2025-11-21T13:53:00Z

Remove endpoint number 'ep_num' argument and memory operation from xhci_log_ctx() trace function. These changes were added in commit 1d27fabec068 ("xhci: add xhci_address_ctx trace event") on Aug 14, 2013 and have never been used. Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251119142417.2820519-14-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

usb: xhci: implement USB Port Register Set struct

2025-11-21T13:53:00Z

Previously, each port's 'addr' field pointed to the base of the Host Controller USB Port Register Set, and specific registers were accessed using macros such as (port->addr + PORTPMSC). This patch replaces the raw '__le32 __iomem *addr' pointer with a typed 'struct xhci_port_regs __iomem *port_reg' pointer. With this change, individual registers can be accessed directly through the structure fields: Before: port->addr port->addr + PORTPMSC port->addr + PORTLI port->addr + PORTHLPMC After: port->port_reg->portsc port->port_reg->portpmsc port->port_reg->portli port->port_reg->porthlpmc This improves code readability and makes register access more intuitive by using named struct members instead of pointer arithmetic and macros. Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20251119142417.2820519-9-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman