CVE-2026-64348 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
usb: free iso schedules on failed submit
EHCI and FOTG210 isochronous submits build an ehci_iso_sched before linking the URB to the endpoint queue, and keep the staged schedule in urb->hcpriv until iso_stream_schedule() and the link helpers consume it. If the controller is no longer accessible, or usb_hcd_link_urb_to_ep() fails, submit jumps to done_not_linked before that handoff happens and leaks the staged schedule still attached to urb->hcpriv.
Free the staged schedule from done_not_linked when submit fails before the URB is linked and clear urb->hcpriv after the free.
The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1.
An x86_64 allyesconfig build showed no new warnings. As we do not have an EHCI host controller with a USB isochronous device to test with, no runtime testing was able to be performed.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/26/2026
This vulnerability resides within the Linux kernel's USB subsystem, specifically affecting the Enhanced Host Controller Interface and Fully On-chip Transfers for 210 controllers that handle isochronous data transfers. The flaw manifests in the improper memory management during USB isochronous transfer submission processes where the kernel fails to correctly release allocated resources when transfer operations encounter failures. The issue stems from the asynchronous nature of isochronous scheduling where intermediate data structures are prepared before final linking occurs, creating a potential memory leak scenario.
The technical implementation flaw occurs in the USB host controller driver code where isochronous schedules are allocated and staged in the URB's hcpriv field before being properly linked to the endpoint queue. When submission fails due to controller unavailability or link operation failures, the code path transitions to done_not_linked label without cleaning up the staged schedule that remains attached to urb->hcpriv. This creates a memory leak condition where allocated isochronous scheduling structures are not freed, leading to gradual resource exhaustion over time. The vulnerability specifically affects the ehci_iso_sched data structure management and demonstrates poor error handling in resource cleanup operations.
The operational impact of this vulnerability extends beyond simple memory consumption as it represents a potential denial-of-service vector that could degrade system performance or cause complete system instability under sustained isochronous traffic loads. Memory leaks in kernel space can accumulate over time, especially when multiple failed isochronous transfers occur, potentially leading to system crashes or resource exhaustion attacks. The issue affects systems running Linux kernel versions including v7.1.1 and demonstrates the importance of proper error path handling in kernel memory management. This vulnerability aligns with CWE-401: Improper Release of Memory and represents a classic case of resource leak in kernel-level programming where cleanup operations are bypassed during error conditions.
The mitigation strategy involves modifying the error handling code path to explicitly free the staged isochronous schedule when submission fails before URB linking occurs, followed by clearing the urb->hcpriv field to prevent stale references. This approach follows established security practices for memory management in kernel space and aligns with ATT&CK technique T1547.001: Registry Run Keys/Startup Folder which emphasizes proper resource cleanup during error conditions. The fix ensures that all allocated resources are properly accounted for regardless of execution path taken, preventing the accumulation of leaked memory structures that could be exploited by malicious actors. This vulnerability highlights the critical need for comprehensive testing of error paths and the importance of automated analysis tools in identifying memory management issues in complex kernel subsystems.
The vulnerability was initially detected through an experimental analysis tool designed to identify kernel memory-management bugs, demonstrating the value of automated static analysis in modern security practices. While no runtime testing could be performed due to lack of appropriate hardware, the manual inspection confirms the persistence of this issue across multiple kernel versions, indicating a fundamental design flaw rather than a transient problem. The absence of warnings during allyesconfig build suggests that the memory leak occurs in code paths that are not typically exercised under normal system operation, making detection more challenging and emphasizing the need for comprehensive testing strategies. This finding reinforces the importance of thorough error path validation in kernel development and demonstrates how seemingly minor resource management issues can have significant security implications.