CVE-2026-80861: usb: xhci: bail out of setup if the controller is inaccessible
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: bail out of setup if the controller is inaccessible
xhcigensetup() locates the operational registers using the capability length read from the very first register:
xhci->opregs = hcd->regs + HCLENGTH(readl(&xhci->capregs->hccapbase));
If the controller is dead or has dropped off the bus, that read returns ~0, HCLENGTH() truncates it to 0xff, and opregs ends up 0xff bytes past the page-aligned MMIO base, i.e. unaligned. The first access through it, xhcihalt() -> xhcihandshake() reading opregs->status, is then an unaligned readl() on device memory. arm64 faults on unaligned device accesses, so instead of xhcihandshake() 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 : xhcihalt [xhcihcd] Call trace: xhcihalt xhcigensetup xhcipcisetup usbaddhcd usbhcdpciprobe xhcipcicommonprobe xhcipcirenesasprobe
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 xhcihandshake() and xhcireset() already test for), abort setup with -ENODEV before opregs is derived from it. Reading it once also avoids re-reading a register that may change under a concurrent hot-removal.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.158.1-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.111-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.1.13-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.111-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.10.273 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.15.224 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.158 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.111 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.51 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.1.13 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.3 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.116-1Fixed in 7.2.15-1Fixed in 7.3.3-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.115-2~deb12u1 - Compensating control
In xhci_gen_setup(), read the xHCI capability register once, check whether it returns the all-ones value (~0), and abort setup with -ENODEV before deriving op_regs from the capability length.
Event History
Frequently Asked Questions
Which systems are most likely to experience a kernel fault from this issue?
The described failure specifically affects arm64 systems, where an unaligned read from device memory faults. It occurs when an xHCI USB controller is dead, inaccessible, or has dropped off the bus during controller setup.
What conditions trigger the failure?
The controller's initial capability-register read must return an all-ones value, such as when the device cannot be accessed. The provided example shows a controller that could not transition from D3cold to D0 before the kernel attempted to initialize it.
How can an administrator identify that this issue has occurred?
Kernel logs may report that the xHCI controller is inaccessible, followed by registration of a new USB bus and an alignment-fault kernel oops. The example includes an "Unable to change power state from D3cold to D0" message and an "Unable to handle kernel paging request" alignment fault in xhci_halt or xhci_handshake.