The bug originates in the xhci host controller setup routine. When the controller is dead or has dropped off the bus, the driver reads the first capability register and interprets any 0xFFFFFFFF value as the length of the operational registers. Truncating that all‑ones value to 0xff produces a pointer that is 0xff bytes past the MMIO base, causing an unaligned read on ARM64. The result is a kernel oops that brings the system down, reset, or requires a reboot. An attacker could trigger this by forcing a power state failure or hot‑removal of the USB controller, thereby causing the driver to crash. The impact is a denial of service at the kernel level.

This issue affects the Linux kernel wherever the xhci host controller code is present and the controller is subject to accidental or malicious power state changes. It applies to all kernel versions that implement the buggy path before the fix commit (for example, older 6.x releases that predates the 0b31744 patch). No explicit version range is supplied, but any kernel using the xhci code without the all‑ones capability check is vulnerable.

EPSS data is unavailable and the vulnerability is not listed in CISA KEV, but the absence of a public exploit does not diminish the severity: a kernel crash is a catastrophic failure. The likely attack vector is local, requiring a device that can be powered off or moved while the kernel is enumerating it. In constrained environments with hard‑or soft‑disabled power management, the risk is elevated. While the exploit cannot be carried out purely over the network, it can serve as a reliable denial‑of-service in hosted environments that rely on USB connectivity.