CVE-2026-64337 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
usb: mtu3: unmap request DMA on queue failure
mtu3_gadget_queue() maps the request before checking whether the QMU GPD ring can accept another transfer. the request is returned with -EAGAIN before it is linked on the endpoint request list if mtu3_prepare_transfer() fails.
Normal completion and dequeue paths unmap requests from mtu3_req_complete(), but this error path never reaches that helper, so the DMA mapping is left active. Unmap the request before returning from the failed queue path.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/25/2026
The vulnerability described represents a critical memory management issue within the Linux kernel's USB multi-threaded unit 3 (mtu3) gadget driver implementation. This flaw occurs in the usb: mtu3: unmap request DMA on queue failure scenario where the system fails to properly clean up DMA mappings during error conditions. The vulnerability stems from improper resource management practices that leave DMA mappings active when transfer operations fail, creating potential security implications for embedded systems and devices relying on USB gadget functionality.
The technical flaw manifests in the mtu3_gadget_queue() function which performs a sequence of operations that creates an inconsistent state. Initially, the function maps the request using appropriate DMA mapping routines before proceeding to validate whether the QMU GPD ring can accommodate another transfer. When mtu3_prepare_transfer() fails and returns -EAGAIN, the system correctly identifies the queue failure condition but fails to execute the necessary cleanup routine. This error path bypasses the normal completion and dequeue mechanisms that would typically invoke mtu3_req_complete() for proper DMA unmapping, leaving the request's DMA mapping in an active state.
The operational impact of this vulnerability extends beyond simple resource leak concerns to potentially enable several attack vectors within embedded systems environments. When DMA mappings remain active after failed queue operations, they can create opportunities for memory corruption scenarios or facilitate privilege escalation attacks. The incomplete cleanup operation creates a persistent mapping that may be exploited by malicious actors to manipulate memory contents or gain unauthorized access to system resources. This issue particularly affects devices implementing USB gadget functionality where the mtu3 driver serves as the underlying communication layer.
This vulnerability aligns with CWE-404, which specifically addresses improper resource management and incomplete cleanup operations in software systems. The flaw demonstrates poor defensive programming practices where error handling paths fail to maintain system consistency through proper resource cleanup mechanisms. From an attacker perspective, this represents a potential entry point for exploitation within the ATT&CK framework under the T1059.001 technique for command execution and T1068 technique for exploit development through kernel vulnerabilities. The incomplete DMA unmapping creates memory state inconsistencies that could be leveraged to craft targeted attacks against embedded devices.
Mitigation strategies should focus on implementing comprehensive error handling within the mtu3 driver's queue failure path. The solution requires ensuring that any request mapping performed during the queue operation is properly unmapped regardless of whether the operation succeeds or fails. This involves modifying the mtu3_gadget_queue() function to include explicit DMA unmap calls before returning from error conditions, particularly when mtu3_prepare_transfer() fails and -EAGAIN is returned. System administrators should prioritize applying kernel updates that contain this fix and monitor for any unusual memory behavior in USB gadget implementations. Additionally, implementing proper logging mechanisms around DMA operations can help detect potential exploitation attempts by monitoring for abnormal mapping patterns or resource usage anomalies in affected systems.
The resolution of this vulnerability demonstrates the critical importance of maintaining consistent resource management practices throughout all code paths, including error handling scenarios. Proper defensive programming requires that every resource allocation have a corresponding deallocation regardless of execution flow, which is fundamental to preventing memory leaks and associated security implications in kernel space operations.