CVE-2026-43432

What it actually does

This is a Linux kernel memory-management flaw in the USB xHCI host controller driver. In an error path inside xhci_disable_slot(), the kernel frees only the xHCI command object with kfree() but does not free the associated completion object allocated by xhci_alloc_command(..., true). If the affected path is reached repeatedly, kernel memory can be leaked until system memory pressure causes degraded performance, failed allocations, service instability, or a denial of service. The CVSS vector indicates local access with low privileges is required, with no confidentiality or integrity impact and high availability impact.

Why it matters to the business

Successful exploitation could make affected Linux systems unstable or unavailable, especially systems that rely on USB/xHCI hardware paths or experience repeated USB device churn. The current EPSS is very low, the vulnerability is not listed in CISA KEV, and no exploit maturity is reported, so broad internet-scale exploitation is unlikely; however, availability-sensitive systems should still receive kernel updates through normal patch cycles because kernel memory leaks can cause outages when triggered repeatedly.

How an attack unfolds

An attacker with local access attempts to force the Linux USB xHCI driver through the abnormal error-handling path in xhci_disable_slot(). This may involve repeatedly causing USB device slot disable operations, USB enumeration failures, device resets, disconnect/reconnect behavior, or other xHCI error conditions. When the vulnerable path is reached, the kernel releases the command structure but leaks the completion structure. Repeating the action can gradually consume kernel memory. Over time, the system may experience increasing memory pressure, allocation failures, hung services, degraded performance, or a crash/reboot due to out-of-memory conditions. Reliable runtime triggering may depend on specific hardware, controller behavior, and abnormal USB state, and the original report notes that a reliable runtime test case was not constructed.

How to fix it

Apply the Linux kernel fix from the relevant distribution or kernel vendor as soon as it is available. The code-level fix is to replace the incorrect kfree() cleanup in xhci_disable_slot() with xhci_free_command(), which frees both the xHCI command structure and its associated completion structure. No exact fixed package versions were provided in the input, so track the advisory for the deployed distribution/kernel branch and upgrade to the first vendor kernel containing the upstream fix. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting physical or virtual USB device passthrough, disabling unnecessary USB functionality where operationally feasible, and monitoring systems that experience frequent USB device churn or xHCI errors.

How to confirm the fix worked

Confirm that the running kernel includes the vendor backport or upstream patch for the xHCI xhci_disable_slot() memory leak. Validate using the distribution advisory, kernel changelog, source package diff, or by checking that the affected code path uses xhci_free_command() instead of kfree() for xHCI command cleanup. After patching, reboot into the fixed kernel and verify with uname -a or package-manager kernel inventory that the fixed kernel is active, not merely installed. Where feasible, perform controlled USB attach/detach or reset testing while monitoring dmesg, journalctl -k, slab usage, and memory pressure to confirm there is no progressive kernel memory growth under repeated xHCI error conditions.

Typical attack path

1. Gain local access to an affected Linux system with the ability to interact with USB/xHCI device state or trigger relevant kernel USB operations.
2. Induce repeated USB xHCI slot disable activity or abnormal USB controller/device states, such as repeated device attach/detach, reset, failed enumeration, or error recovery paths.
3. Cause xhci_disable_slot() to enter the vulnerable error-handling path.
4. Repeat the trigger so the associated completion structures are leaked in kernel memory.
5. Continue until kernel memory pressure causes allocation failures, degraded service availability, system instability, or denial of service.

How to detect it

To assess possible prior exploitation, review kernel logs, system journals, and endpoint telemetry for repeated USB xHCI error activity followed by increasing memory pressure or out-of-memory behavior. Useful sources include journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, /var/log/syslog, auditd logs for local user activity, EDR process/session telemetry, and hypervisor logs if USB passthrough is used. Look for bursts of USB disconnect/reconnect/reset or xHCI slot disable/enumeration failures, especially when correlated with rising slab/kernel memory usage, failed kernel allocations, hung tasks, OOM killer activity, or unexpected reboots. There are no known public exploit-specific payload strings for this issue; detection should rely on behavioral correlation between local user activity, USB/xHCI error paths, and progressive memory exhaustion.

• xhci_hcd
• usb disconnect
• new SuperSpeed USB device number
• reset SuperSpeed USB device
• device descriptor read/64, error
• device not accepting address
• unable to enumerate USB device
• Not enough host controller resources
• Out of memory: Killed process
• oom-killer
• page allocation failure
• Memory allocation failure
• kernel: xhci_hcd
• kernel: usb
• kernel: oom-killer

What your security team should do

• Inventory Linux systems using affected kernel versions and USB xHCI host controller support, prioritizing servers, workstations, virtualization hosts, embedded systems, and appliances where local users or USB passthrough are present.
• Patch through the operating system or appliance vendor kernel update channel once a fixed kernel is available, then reboot to activate the fixed kernel.
• Prioritize availability-sensitive systems and systems exposed to untrusted local users, shared shell access, kiosk use, lab environments, or untrusted USB devices.
• Until patched, restrict local interactive access and disable or tightly control USB device passthrough, hotplug, and physical USB access where feasible.
• Monitor kernel logs and memory telemetry for repeated xHCI errors, USB device churn, kernel allocation failures, and out-of-memory events.
• Because this is not currently in KEV, has low EPSS, and has no reported public exploit maturity, handle it as a defense-in-depth kernel availability fix unless local attack exposure or USB-heavy workloads increase risk.