CVE-2026-64144

What it actually does

This is a Linux kernel memory leak in the MediaTek Bluetooth USB driver path. When a Bluetooth control URB is created, its setup_packet allocation is not released if usb_submit_urb fails or if the submitted URB is later killed. Repeatedly triggering these error paths can consume kernel memory over time, potentially leading to Bluetooth instability, kernel memory pressure, out-of-memory conditions, or system denial of service. The issue is not known to enable code execution, privilege escalation, or direct data disclosure.

Why it matters to the business

Systems using affected Linux kernels with MediaTek Bluetooth USB hardware may become unstable or unavailable if the vulnerable driver path is repeatedly triggered. The most likely operational impact is degraded Bluetooth functionality, service interruption, or a host crash/reboot due to memory exhaustion. Public exploitation maturity is currently reported as none, EPSS is low, and the issue is not listed in CISA KEV, so this should generally be prioritized as routine kernel hygiene unless the organization depends on Bluetooth availability or operates exposed/shared physical endpoints.

How an attack unfolds

An attacker first needs a way to influence the vulnerable Bluetooth USB driver path, such as local access to a system using the MediaTek btmtk driver, physical/proximal interaction with Bluetooth/USB hardware, or another condition that repeatedly causes Bluetooth control URB submission failures or URB cancellation. The attacker then repeatedly exercises the failing control path. Each failed or killed URB can leave its setup_packet allocation unreleased. Over many iterations, these leaked allocations accumulate in kernel memory. If sustained long enough, the host may experience increasing memory pressure, degraded Bluetooth operation, OOM killer activity, service failures, or a crash/reboot. There is no indication from the provided information that exploitation provides arbitrary code execution or data access.

How to fix it

Update to a Linux kernel version from the relevant distribution or vendor that includes the btmtk fix freeing urb->setup_packet in both usb_submit_urb failure and killed-URB paths. No exact fixed package versions were provided in the input, so use the affected distribution’s kernel security advisory or stable kernel changelog to identify the corrected build. Where immediate patching is not possible, reduce exposure by disabling Bluetooth where not required, removing or disabling affected MediaTek Bluetooth USB hardware, unloading or blacklisting the btmtk driver if operationally acceptable, restricting physical USB access, and monitoring for kernel memory exhaustion. Reboots may temporarily recover leaked memory but do not remediate the vulnerability.

How to confirm the fix worked

Confirm that deployed kernels include the upstream or vendor patch for the Bluetooth btmtk setup_packet leak. Validate the running kernel package version against vendor advisories rather than only checking installed packages. On representative systems, verify whether the btmtk module is loaded and whether MediaTek Bluetooth USB devices are present. For deeper validation, use a controlled test environment with kernel memory leak detection, slab monitoring, or fault injection around btmtk control URB submission paths to confirm repeated failure or cancellation no longer increases unreclaimed kernel memory. After remediation, monitor for absence of recurring Bluetooth driver errors, OOM events, and unexplained kernel memory growth.

Typical attack path

1. Identify a Linux system using an affected kernel and the MediaTek btmtk Bluetooth USB driver.
2. Gain the ability to interact with or disrupt the Bluetooth/USB device path locally, physically, or through a proximate Bluetooth/USB-triggered condition.
3. Repeatedly trigger Bluetooth control URB submission failures or URB kill paths.
4. Cause repeated setup_packet allocations to remain unreleased in kernel memory.
5. Accumulate kernel memory pressure until Bluetooth services degrade, processes are killed, or the system becomes unstable or unavailable.

How to detect it

There are no reliable, CVE-specific indicators proving exploitation from logs alone. Detection should focus on behavioral evidence: systems with the btmtk module loaded, recurring Bluetooth or USB control-transfer errors, repeated device resets or disconnects, unexplained kernel memory growth, OOM killer activity, and service failures or reboots following Bluetooth/USB instability. Useful log sources include kernel logs, system journal, dmesg output, endpoint telemetry, EDR process/crash timelines, and hardware inventory showing MediaTek Bluetooth USB devices. Analysts should correlate repeated btmtk/Bluetooth/USB errors with rising memory pressure and subsequent OOM or reboot events. Also distinguish malicious triggering from failing Bluetooth hardware, flaky USB ports, power-management issues, or driver bugs unrelated to exploitation.

• btmtk
• Bluetooth:
• usb_submit_urb
• urb
• setup_packet
• Out of memory: Killed process
• oom-killer
• invoked oom-killer
• USB disconnect
• reset full-speed USB device
• reset high-speed USB device
• MediaTek Bluetooth

What your security team should do

• Inventory Linux endpoints and appliances using Bluetooth, especially those with MediaTek Bluetooth USB hardware or the btmtk kernel module loaded.
• Prioritize kernel updates on systems where Bluetooth is required, systems with shared physical access, kiosks, desktops, lab machines, or devices that cannot tolerate unexpected reboot or service interruption.
• If patching must be delayed, disable Bluetooth or blacklist the btmtk module where business operations allow.
• Add monitoring for unusual kernel memory growth, Bluetooth driver errors, USB reset loops, and OOM killer activity on systems with btmtk loaded.
• Treat confirmed repeated btmtk/USB errors followed by memory exhaustion as a potential denial-of-service attempt or hardware fault requiring investigation.
• Because this is not KEV-listed, has low EPSS, and has no reported exploit maturity, schedule remediation according to normal kernel patch cycles unless local exposure or operational dependence increases risk.