CVE-2026-64465

What it actually does

This is a Linux kernel denial-of-service flaw in the xHCI USB host controller driver. When a USB device using active stream endpoints is disconnected, the kernel frees stream resources while holding the xHCI lock with interrupts disabled. That cleanup path can call dma_free_coherent(), which may sleep, but sleeping is not allowed in atomic context. The result can be a kernel BUG, warning, crash, hang, or system instability during USB device removal. Exploitation requires the ability to connect, control, or trigger disconnect behavior for a USB device that uses xHCI stream endpoints, such as certain USB 3.x devices using stream-capable endpoints.

Why it matters to the business

Successful exploitation can cause affected Linux systems to crash or become unstable, disrupting workloads, kiosks, appliances, embedded systems, desktops, servers with USB-attached devices, and operational technology systems that rely on continuous availability. The risk is highest where untrusted users can attach USB devices, where USB peripherals are remotely controllable, or where systems automatically interact with removable USB hardware. The currently provided EPSS is low and the issue is not known to be in CISA KEV or ransomware campaigns, so broad internet-scale exploitation is unlikely; however, physical or local-access denial of service may still be operationally significant.

How an attack unfolds

An attacker first obtains a path to influence USB hardware attached to a vulnerable Linux system, typically through physical access, a malicious USB peripheral, a compromised USB device, or a controllable USB connection. The attacker presents a USB device with stream-capable endpoints and causes the operating system to allocate active xHCI stream resources. The attacker then triggers device disconnect, reset, unbind, or removal behavior while those streams are active. During the resulting hub event and USB teardown path, xhci_free_streams() attempts to free stream information while holding the xHCI lock with interrupts disabled. The cleanup path reaches dma_free_coherent(), which can sleep, causing an invalid sleep-in-atomic-context condition. Depending on kernel configuration and runtime state, the system may emit a BUG or warning, crash, panic, hang, or lose USB subsystem stability.

How to fix it

Apply a Linux kernel update from the operating system, appliance, or distribution vendor that includes the xHCI fix for freeing stream resources outside the locked atomic section. Where exact package versions are not available, track the vendor advisory for this CVE and update to the first fixed kernel build or a later supported build. Reboot into the updated kernel after installation and remove older vulnerable kernels where operationally feasible. If immediate patching is not possible, reduce exposure by restricting physical USB access, disabling unused USB ports in firmware or operating-system policy, blocking untrusted USB devices, disabling USB autosupport in high-risk environments, and avoiding use of untrusted USB 3.x peripherals that may exercise stream endpoints. For servers and appliances that do not require USB, consider disabling USB host controller support or blacklisting nonessential USB device classes according to operational requirements.

How to confirm the fix worked

Confirm that the running kernel is a vendor-fixed build, not merely that an updated package is installed. Validate with commands such as uname -a, package manager kernel version checks, and vendor advisory mapping for the relevant distribution or appliance. Confirm the system was rebooted into the fixed kernel. Review kernel changelogs or vendor patches for the xHCI change that moves xhci_free_stream_info() out from under xhci->lock / atomic context in xhci_free_streams(). For exposure validation, identify systems with enabled xHCI USB host controllers and accessible USB ports. Where safe in a test environment only, reproduce with controlled stream-capable USB hardware before and after patching to verify that disconnect no longer produces sleep-in-atomic-context BUG messages or crashes.

Typical attack path

1. Gain physical, local, or device-level ability to attach or control a USB device connected to a vulnerable Linux system.
2. Present or emulate a USB device that uses stream-capable endpoints handled by the xHCI driver.
3. Cause the kernel to allocate active stream resources for the device.
4. Trigger disconnect, reset, driver unbind, or removal while the stream endpoints remain active.
5. The USB hub event teardown path calls xhci_free_streams() and reaches a sleep-capable DMA free operation while in atomic context.
6. The kernel reports a BUG or invalid-context warning and may crash, hang, or destabilize the USB subsystem.

How to detect it

Look for evidence of kernel crashes, panics, BUG reports, or invalid sleep-in-atomic-context warnings associated with USB disconnect events and the xHCI driver. Primary log sources include kernel ring buffer output, persistent journal logs, syslog, kern.log, messages, crash dumps, kdump/vmcore artifacts, and system reboot telemetry. Search for call traces containing xhci_free_streams(), xhci_free_stream_info(), xhci_free_stream_ctx(), dma_free_coherent(), dma_free_attrs(), usb_disconnect(), usb_disable_device(), usb_unbind_interface(), and hub_event(). Correlate findings with timestamps of USB device insertion/removal, unexpected reboots, kernel panics, watchdog resets, or loss of USB functionality. Because this is a denial-of-service issue rather than a code-execution flaw, exploitation may leave only kernel log artifacts and crash evidence, not attacker-created files or persistent processes. If kernel logs are volatile and lost after reboot, review crash dump infrastructure, systemd journal persistence, out-of-band management event logs, and endpoint telemetry for abrupt shutdowns following USB disconnect activity.

• BUG: sleeping function called from invalid context
• sleeping function called from invalid context
• dma_free_attrs
• dma_free_coherent
• xhci_free_stream_info
• xhci_free_stream_ctx
• xhci_free_streams
• usb_free_streams
• usb_unbind_interface
• usb_disable_device
• usb_disconnect
• hub_event
• process_one_work
• Call trace:
• xhci->lock
• kernel BUG
• BUG: kernel NULL pointer dereference
• Kernel panic
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /var/crash/
• /proc/vmcore

What your security team should do

• Prioritize patching Linux systems where untrusted users can physically access USB ports, including kiosks, shared workstations, point-of-sale devices, lab systems, and edge appliances.
• Update vulnerable systems to a vendor-fixed kernel and ensure they are rebooted into the fixed version.
• For critical servers that do not require USB, disable or restrict USB host controllers and removable-device support as a defense-in-depth measure.
• Add monitoring for kernel BUG, panic, and sleep-in-atomic-context messages involving xHCI, USB disconnect, and stream cleanup paths.
• Review recent crashes or unexpected reboots on Linux systems with USB activity for evidence of this call trace.
• Restrict physical access to USB ports and enforce device-control policies for removable and emulated USB devices.
• Track vendor advisories for exact fixed kernel versions because no product-specific fixed versions were provided in the input.
• Treat exploitation likelihood as low in remote threat models, but do not ignore the issue in environments where physical access or malicious peripherals are realistic.