CVE-2026-80861
NoneCVSS
—
EPSS
0.2%
Published
Sep 4, 2026
CISA due date
—
Cloudanix analysis
Broken USB hardware can make some computers crash during startup instead of handling the problem gracefully.
- Exploitation
- Physical Access
- Attacker needs
- Physical Access
- Complexity
- Theoretical
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Improper Input Validation
- Remediation
- Patch
- Effort
- Low
- Patch risk
- Low
What it actually does
When an xHCI controller is dead or inaccessible, reading the capability base register returns ~0; HC_LENGTH truncates it to 0xff, miscalculating op_regs and causing an unaligned MMIO readl in xhci_halt that triggers an alignment fault and kernel oops on arm64.
Why it matters to the business
Systems using affected USB hardware may suffer kernel crashes during boot or USB initialization when controllers fail to power up, resulting in downtime and requiring hardware or kernel intervention.
How an attack unfolds
An attacker or environmental condition causes an xHCI controller (such as Renesas uPD720201) to become inaccessible during power-state transition; the subsequent HCD probe path executes the flawed xhci_gen_setup, producing the unaligned access and oops before any error handling can occur.
How to fix it
Apply the kernel patch that reads the capability register once, checks for the all-ones value, and aborts setup with -ENODEV before deriving op_regs; update to a kernel containing the fix for this issue.
How to confirm the fix worked
Confirm the capability-register all-ones guard exists in xhci_gen_setup; reproduce the inaccessible-controller scenario and verify graceful -ENODEV return instead of oops.
Typical attack path
- Cause or wait for xHCI controller to report D3cold-to-D0 failure and become inaccessible
- Trigger USB host-controller detection and probe via usb_add_hcd
- Execute xhci_pci_setup → xhci_gen_setup which derives op_regs from all-ones value
- Perform unaligned read in xhci_halt leading to alignment fault and kernel oops
How to detect it
Inspect kernel logs for xHCI probe sequences followed by paging-request or alignment-fault oopses referencing xhci_halt or xhci_gen_setup; correlate with power-state transition errors on USB controllers.
- Unable to change power state from D3cold to D0, device inaccessible
- Unable to handle kernel paging request at virtual address
- ESR = 0x0000000096000021
- FSC = 0x21: alignment fault
- xhci_halt [xhci_hcd]
- xhci-pci-renesas
What your security team should do
- Apply patched kernel versions to all systems exposing xHCI controllers
- Monitor boot and kernel logs for xHCI power-state and alignment-fault messages
- Replace persistently failing USB hardware that triggers the probe path
The record
In the Linux kernel, the following vulnerability has been resolved: usb: xhci: bail out of setup if the controller is inaccessible 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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|