CVE-2026-64337

What it actually does

This flaw is a Linux kernel driver bug in the MediaTek USB3 dual-role/gadget controller driver, commonly referred to as mtu3. When a USB gadget request is queued, the driver maps the request for DMA before confirming that the QMU GPD transfer ring has capacity. If the ring cannot accept the transfer, the queue operation fails and returns -EAGAIN, but the DMA mapping is not released on that error path. Normal request completion and dequeue paths do unmap DMA, but this failed-queue path bypasses those cleanup routines. The result is a leaked/stale DMA mapping that can accumulate under repeated failure conditions, potentially causing DMA API warnings, resource exhaustion, USB gadget malfunction, IOMMU/DMA instability, or kernel/device reliability issues. There is no indication from the provided data that this is a practical remote code execution vulnerability.

Why it matters to the business

Organizations using Linux-based products with MediaTek USB gadget/peripheral functionality may experience USB service instability, device hangs, kernel warnings, or degraded reliability if the vulnerable code path is repeatedly triggered. The most relevant exposure is embedded, mobile, appliance, or IoT-style systems that use the mtu3 USB gadget driver. The currently provided exploit maturity is none, EPSS is very low, and it is not listed in CISA KEV or associated with ransomware, so broad active exploitation appears unlikely; however, kernel reliability defects in widely reused Linux components should still be remediated through normal kernel update processes, especially for devices exposed to untrusted USB hosts or users able to configure USB gadget functions.

How an attack unfolds

An attacker would need a way to drive the affected USB gadget queueing path on a system using the vulnerable mtu3 driver. In a realistic scenario, this could involve a malicious or untrusted USB host interacting with a Linux device operating in USB gadget/peripheral mode, or a local user/process with permission to configure or exercise USB gadget interfaces through mechanisms such as configfs, FunctionFS, or gadget-specific services. The attacker repeatedly causes requests to be queued while the QMU GPD ring is full or unable to accept another transfer. Each failed queue attempt can return -EAGAIN after the request has already been DMA-mapped, leaving the mapping active. Repetition can accumulate leaked DMA mappings and lead to DMA API diagnostics, IOMMU pressure, endpoint failures, USB gadget disruption, or broader device instability. The known impact is primarily denial-of-service or reliability degradation rather than confirmed privilege escalation or code execution.

How to fix it

Update the Linux kernel to a version that includes the upstream fix for the mtu3 driver change titled "usb: mtu3: unmap request DMA on queue failure." If using a vendor or distribution kernel, apply the vendor-provided kernel update once available. If maintaining a custom kernel, backport the patch that unmaps the request before returning from the failed mtu3_gadget_queue() path when mtu3_prepare_transfer() fails. Where immediate patching is not possible, reduce exposure by disabling unused USB gadget/peripheral functionality, unloading or not building the mtu3 driver where not required, limiting access to USB gadget configuration interfaces such as configfs/FunctionFS, and preventing untrusted physical USB host connections to affected devices. Systems that do not include or load the mtu3 driver, or do not operate the MediaTek USB controller in gadget mode, are unlikely to be affected by this specific flaw.

How to confirm the fix worked

Confirm that the running kernel or vendor kernel package includes the mtu3 DMA unmap fix. For source-based validation, inspect the mtu3 gadget queue failure path and verify that when mtu3_prepare_transfer() fails after DMA mapping, the request is unmapped before returning -EAGAIN. Confirm whether exposure exists by checking kernel configuration and runtime state for mtu3 support, such as CONFIG_USB_MTU3, loaded mtu3-related modules, device tree/platform references to MediaTek USB3 controllers, and active USB gadget configuration. For functional validation, enable kernel DMA debugging in a non-production test environment, stress USB gadget transfers until the queue/ring is full, and confirm that failed queue attempts do not produce DMA mapping leaks or persistent DMA-API warnings. Also verify that normal USB gadget operation continues without endpoint stalls or repeated controller resets after the update.

Typical attack path

1. Identify or access a Linux device using the MediaTek mtu3 USB gadget/peripheral driver.
2. Interact with the device as a USB host, or obtain local permission to configure/exercise USB gadget functions.
3. Generate high-volume or carefully timed USB gadget transfers to pressure the endpoint queue and QMU GPD ring.
4. Trigger the mtu3_gadget_queue() failure path where mtu3_prepare_transfer() fails and returns -EAGAIN.
5. Repeat the condition so DMA mappings are leaked instead of being unmapped.
6. Cause USB gadget malfunction, kernel DMA/IOMMU warnings, resource exhaustion, or device instability.

How to detect it

This vulnerability is unlikely to leave classic compromise artifacts such as malware files, persistence keys, or command-and-control traffic. Detection should focus on evidence that the affected driver path was repeatedly exercised and caused DMA/resource leakage or USB gadget instability. Review kernel logs from dmesg, journalctl -k, /var/log/kern.log, and distribution-specific system logs for DMA-API warnings, IOMMU faults, mtu3 driver errors, repeated USB gadget queue failures, endpoint stalls, controller resets, or recurring -EAGAIN conditions during USB gadget activity. Correlate timestamps with physical USB connection events, changes under /sys/kernel/config/usb_gadget, FunctionFS activity, gadget service restarts, or unexpected local processes interacting with USB gadget endpoints. In forensic or engineering investigations, inspect whether DMA debugging reported leaked mappings and whether the system was operating in USB gadget/peripheral mode at the time. Because no public exploit maturity or KEV listing is indicated, findings should be interpreted primarily as potential attempted denial-of-service, fuzzing, stress testing, or device reliability abuse rather than confirmed intrusion.

• mtu3
• mtu3_gadget_queue
• mtu3_prepare_transfer
• DMA-API:
• device driver has pending DMA allocations
• DMA-API: debugging out of memory
• IOMMU fault
• -EAGAIN
• usb_gadget
• /sys/kernel/config/usb_gadget
• FunctionFS
• ffs
• endpoint stalled
• controller reset

What your security team should do

• Inventory Linux kernels and embedded/device firmware that include MediaTek mtu3 USB gadget support, prioritizing internet-managed, field-deployed, kiosk, appliance, mobile, and IoT devices.
• Patch through vendor kernel updates or backport the upstream mtu3 fix during the next kernel maintenance cycle; accelerate patching for devices exposed to untrusted USB hosts or local users with gadget configuration access.
• Disable unused USB gadget/peripheral mode and restrict access to configfs, FunctionFS, and any service that can create or drive USB gadget endpoints.
• Monitor kernel logs for DMA-API warnings, IOMMU faults, repeated mtu3 messages, USB endpoint stalls, and unexpected gadget controller resets.
• For custom kernels, add regression testing that saturates USB gadget endpoint queues and verifies DMA mappings are released on all queue failure paths.
• Treat evidence of repeated USB gadget queue failures or DMA mapping exhaustion as a reliability incident and investigate connected USB hosts, local gadget configuration changes, and recent firmware/kernel modifications.