CVE-2026-43488

What it actually does

This is a local denial-of-service flaw in the Linux kernel xHCI USB host controller driver. When certain USB Attached SCSI (UAS) storage plug/unplug or error conditions cause the controller to report a Host Controller Error, vulnerable kernels log the condition but do not halt or quiesce the xHCI controller interrupt path. On affected hardware, the interrupt remains uncleared and can produce an interrupt storm, consuming CPU in kernel interrupt handling and causing severe system instability, hangs, watchdog events, or loss of availability. The issue does not provide confidentiality or integrity impact and is not a remote code execution vulnerability.

Why it matters to the business

Systems that allow local users or peripherals to interact with USB storage may become unstable or unavailable if the vulnerable xHCI error path is triggered. The most likely operational impact is device hang, degraded performance, forced reboot, or service interruption on Linux-based endpoints, appliances, Android-derived devices, kiosks, embedded systems, and servers with accessible USB ports. The current EPSS score is low and it is not listed in CISA KEV, so broad internet-scale exploitation is unlikely, but environments with exposed physical USB ports, untrusted peripherals, or multi-user local access should treat it as a practical availability risk.

How an attack unfolds

An attacker first needs local access sufficient to trigger USB host-controller activity, most commonly by connecting, disconnecting, or emulating a problematic USB/UAS storage device. The attacker then causes the xHCI controller to enter a Host Controller Error state during the UAS plug/unplug or device error sequence. On a vulnerable kernel, the xHCI interrupt handler detects the HCE condition but only logs a warning and does not stop the controller. On affected hosts, interrupts continue firing rapidly because the condition is not cleared, resulting in an interrupt storm. CPU time is consumed in interrupt handling, the kernel may emit repeated xHCI and IRQ-related messages, and the system may become unresponsive, trigger watchdogs, or require a reboot to recover.

How to fix it

Upgrade to a vendor-supported Linux kernel that includes the xHCI fix to halt the controller when STS_HCE is detected in xhci_irq(). No exact fixed package versions were provided, so use the Linux distribution, device vendor, or Android BSP/security bulletin guidance for the affected kernel branch. Where immediate patching is not possible, reduce exposure by restricting physical USB access, disabling or blocking untrusted USB storage, enforcing USB device-control policy, disabling UAS for problematic devices where operationally acceptable, and avoiding use of untrusted USB peripherals. For high-assurance systems, consider firmware/BIOS controls to disable unused USB ports or xHCI where feasible.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version and vendor changelog include the xHCI Host Controller Error interrupt-storm fix. Review kernel package release notes or source patches for the addition of xhci_halt() handling when STS_HCE is detected in xhci_irq(). After patching, test with approved USB/UAS storage plug/unplug scenarios on representative hardware and confirm the system does not enter a sustained interrupt storm or become unresponsive. Operationally, validate that logs no longer show repeated xHCI Host Controller Error warnings followed by IRQ storm symptoms, watchdog events, or forced reboots under normal USB device activity.

Typical attack path

1. Obtain local physical access to a USB port or equivalent local capability to attach or emulate a USB/UAS storage device.
2. Connect, disconnect, or manipulate the USB/UAS device in a way that causes the xHCI controller to report a Host Controller Error.
3. Trigger the vulnerable xHCI interrupt handler path where the HCE status is logged but the controller is not halted.
4. Cause repeated uncleared xHCI interrupts, creating an interrupt storm.
5. Degrade or deny system availability through high interrupt load, kernel instability, hangs, watchdog resets, or forced reboot.

How to detect it

Look for evidence of prior exploitation or accidental triggering in kernel logs, system journals, crash logs, watchdog logs, endpoint telemetry, and reboot history. Useful sources include /var/log/kern.log, /var/log/messages, journalctl -k output, dmesg buffers, pstore/ramoops records, crash dumps, Android logcat/kernel logs, and hardware management controller event logs where available. Focus on repeated xHCI Host Controller Error messages, unusually high interrupt rates for xhci_hcd, IRQ storm messages, soft lockup or RCU stall warnings, watchdog resets, and reboots occurring immediately after USB storage attach/detach events. Correlate timestamps with USB device enumeration logs, UAS driver messages, physical access events, and peripheral-control logs. Because this flaw causes denial of service rather than code execution, there may be no persistent malware artifact; absence of file or process IOCs does not rule out triggering.

• WARNING: Host Controller Error
• Host Controller Error
• xhci_hcd
• usb: xhci
• uas
• usb-storage
• irq storm
• interrupt storm
• nobody cared
• Disabling IRQ #
• soft lockup
• watchdog: BUG: soft lockup
• rcu: INFO: rcu_preempt detected stalls
• rcu_sched detected stalls
• NMI watchdog: Watchdog detected hard LOCKUP
• pstore
• ramoops

What your security team should do

• Prioritize patching Linux systems, embedded devices, Android-derived platforms, kiosks, and appliances where USB ports are physically accessible or untrusted peripherals may be attached.
• Inventory systems using vulnerable Linux kernel branches and xHCI USB controllers, then track vendor kernel updates because no universal fixed version was provided.
• Restrict physical USB access and enforce USB device-control policies for systems that cannot be patched immediately.
• Monitor kernel, system, and endpoint telemetry for repeated xHCI Host Controller Error messages, IRQ storm indicators, soft lockups, watchdog resets, and unexplained reboots following USB activity.
• For critical systems, test representative USB/UAS device plug/unplug workflows after kernel updates to confirm stability.
• Treat this primarily as an availability-control issue; incident response should focus on system stability, reboot timelines, attached USB device history, and local access review rather than credential theft or data exfiltration.