CVE-2026-64350

What it actually does

This is a Linux kernel memory leak in the USB cdnsp driver error-handling path. When cdnsp_alloc_stream_info() allocates a stream context array and a later stream-ring allocation or stream-mapping update fails, the cleanup path frees related stream-ring structures but fails to free the stream context array. Repeatedly triggering that failure path can consume unreclaimed kernel memory and may eventually degrade the system or cause denial of service through memory exhaustion. The issue does not indicate direct code execution or privilege escalation based on the available description.

Why it matters to the business

Systems using affected Linux kernels with the cdnsp USB controller driver may become unstable if the leak is repeatedly triggered, especially on systems with limited memory or exposed USB functionality. The most likely operational impact is service degradation, kernel memory pressure, or system crash/reboot. Current public risk appears low: EPSS is 0.00173, it is not in CISA KEV, is not associated with ransomware, and no public exploit maturity is reported.

How an attack unfolds

An attacker would need a way to exercise the affected cdnsp USB driver code path that allocates USB stream information, then cause a later allocation or mapping operation to fail. This could plausibly involve local access to USB functionality, a malicious or unusual USB device, or local code that repeatedly drives the USB stack while the system is under memory pressure. Each successful trigger leaks the previously allocated stream context array. By repeating the sequence, the attacker may gradually consume kernel memory until the system becomes unstable, experiences allocation failures, or crashes. There is no indication from the supplied data that this vulnerability enables direct compromise, remote exploitation over the network, or arbitrary code execution.

How to fix it

Apply the Linux kernel update that includes the cdnsp_alloc_stream_info() cleanup fix from the kernel or distribution vendor. Because no exact affected products or fixed package versions were provided, use the relevant vendor security advisory, stable kernel release notes, or distribution package changelog to identify the first fixed kernel for each platform. Where immediate patching is not possible, reduce exposure by disabling or unloading the cdnsp driver if it is not required, limiting physical access to USB ports, preventing untrusted USB devices from being connected, and hardening systems against local users that can repeatedly exercise USB functionality. Reboot into the fixed kernel after installation; merely installing a kernel package is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, has been updated to a vendor build containing the cdnsp stream context array cleanup fix. Validate with uname -a, distribution package tools, and vendor advisory metadata. On source-built kernels, confirm the cdnsp_alloc_stream_info() error path frees stream_info->stream_ctx_array before falling through to stream_rings cleanup. If practical in a lab, use kernel fault injection or controlled allocation-failure testing against the cdnsp stream allocation path and verify that repeated failures do not produce unbounded kernel memory growth. Also confirm whether the cdnsp module is loaded or built into the kernel and whether the platform actually uses the affected USB controller driver.

Typical attack path

1. Identify a Linux system running an affected kernel with the cdnsp USB driver present and active.
2. Gain the ability to interact with the relevant USB controller path, such as through local access, a connected USB device, or code that can exercise USB stream allocation.
3. Trigger USB stream information allocation in cdnsp_alloc_stream_info().
4. Force or induce a later stream-ring allocation or stream-mapping update failure, commonly by manipulating device behavior or increasing memory pressure.
5. Repeat the sequence so the stream context array is leaked each time.
6. Continue until kernel memory pressure causes degraded service, allocation failures, instability, or denial of service.

How to detect it

There are no unique public indicators that prove exploitation of this issue from the supplied information. To investigate possible abuse, review kernel logs, system journals, crash dumps, and monitoring data for repeated USB/cdnsp errors followed by sustained kernel memory growth, page allocation failures, OOM killer activity, USB controller resets, or unexpected reboots. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, kernel crash dumps, and endpoint telemetry showing USB device attach/detach activity. Correlate suspicious memory exhaustion with physical access events, newly connected USB devices, or local processes repeatedly interacting with USB interfaces. Absence of these signs does not prove non-exploitation, because a memory leak may leave only generic resource-exhaustion artifacts.

What your security team should do

• Prioritize normal kernel patching through the standard Linux fleet update process; increase priority for appliances, embedded systems, kiosks, or physically accessible systems that use cdnsp USB hardware.
• Inventory systems where the cdnsp driver is present, loaded, or built into the running kernel.
• Where the driver is unnecessary, disable it or remove the module from boot-time loading as a compensating control.
• Restrict untrusted physical USB access, especially on shared, public, or unattended systems.
• Monitor for unexplained kernel memory pressure, OOM events, USB controller resets, or crashes involving USB/cdnsp components.
• Because this is not KEV, has low EPSS, and has no reported exploit maturity, treat it as a stability and local/physical exposure risk rather than an internet-scale emergency unless asset context increases exposure.