CVE-2026-80861

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.