CVE-2026-46140

What it actually does

This flaw is an out-of-bounds read in the Linux kernel MediaTek Bluetooth USB driver path that handles WMT firmware event responses. The vulnerable code casts received SKB data to fixed-size WMT event structures before verifying that the SKB is long enough. A malformed or truncated firmware response can cause the kernel to read past the valid packet buffer into SKB tailroom. Depending on kernel configuration and surrounding memory layout, this may expose kernel memory contents or trigger a kernel fault, panic, or denial of service. The attack surface is local: exploitation generally requires local access and an ability to cause the btmtk USB Bluetooth driver to process a crafted or abnormal MediaTek Bluetooth device/firmware response.

Why it matters to the business

Successful exploitation could crash affected Linux systems or potentially expose sensitive kernel memory, affecting workstation, server, appliance, or embedded deployments that use the MediaTek Bluetooth USB driver. The operational risk is highest for systems where untrusted users can attach USB/Bluetooth hardware, where Bluetooth is enabled by default, or where devices are physically accessible. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, local kernel flaws remain important because they can support privilege escalation chains, physical-access attacks, and reliability failures.

How an attack unfolds

An attacker first obtains local access to a vulnerable Linux system or a situation where they can introduce or influence a MediaTek Bluetooth USB device. They then cause the kernel btmtk driver to initialize or synchronize with the Bluetooth controller. During WMT command synchronization, the device or firmware returns a response shorter than the driver expects. The vulnerable driver treats the short SKB as if it contains a complete WMT event structure and reads fields beyond the valid packet data. The immediate result may be a kernel out-of-bounds read detected by hardening features such as KASAN, a kernel oops/panic, or leakage of adjacent kernel memory depending on build options and exploit technique. There is no public indication from the supplied data that this vulnerability is being actively exploited by named threat actors.

How to fix it

Update to a Linux kernel build that includes the upstream fix for the MediaTek Bluetooth btmtk WMT event length validation issue. The fix validates and advances SKB data with skb_pull_data() before accessing the base WMT event header and validates the additional FUNC_CTRL status bytes before use. Because no exact fixed package versions were provided, obtain the corrected kernel from the relevant Linux distribution, appliance vendor, or kernel maintainer and verify that the vendor advisory explicitly references this issue or the btmtk WMT event SKB length validation patch. Where immediate patching is not possible, reduce exposure by disabling Bluetooth on systems that do not require it, preventing automatic loading of the btmtk_usb driver, restricting local and physical access to USB ports, and enforcing device-control policies for untrusted USB/Bluetooth hardware.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package is a vendor-fixed build or contains the btmtk patch that validates WMT event SKB length before structure access. Reboot into the fixed kernel after installation; merely installing a package is not sufficient if the old kernel remains running. Check whether the btmtk_usb module is present or loaded with commands such as lsmod, modinfo, or equivalent platform tooling, and confirm Bluetooth functionality remains stable after update. For mitigation validation, confirm Bluetooth is disabled where intended, the btmtk_usb module cannot be loaded automatically, and USB device-control policy blocks untrusted Bluetooth adapters. On test systems, kernel logs should no longer show KASAN, UBSAN, oops, or panic messages referencing btmtk WMT synchronization when malformed or short responses are processed.

Typical attack path

1. Identify a Linux system using the affected MediaTek Bluetooth USB driver.
2. Gain local access, physical access, or another path to make the system process a crafted or malformed MediaTek Bluetooth controller response.
3. Trigger Bluetooth controller initialization or WMT synchronization through device attachment, reset, resume, or driver interaction.
4. Return a truncated WMT event response that is shorter than the expected base or FUNC_CTRL structure.
5. Cause the kernel driver to read beyond the valid SKB data.
6. Use the resulting kernel crash for denial of service or attempt to leverage exposed kernel memory as part of a larger local exploit chain.

How to detect it

To determine whether exploitation may have occurred, review host kernel logs, system journals, crash dumps, and endpoint telemetry for failures around MediaTek Bluetooth USB initialization, WMT synchronization, USB Bluetooth attachment, suspend/resume, or driver reload events. Useful log sources include dmesg output, systemd-journald kernel logs, /var/log/kern.log, /var/log/messages, crash dump directories, kernel oops/panic reports, KASAN reports, and EDR telemetry for module load/unload activity. Look for btmtk_usb or btmtk stack traces, out-of-bounds read reports, KASAN slab-out-of-bounds messages, kernel panics shortly after Bluetooth adapter insertion, or repeated USB disconnect/reconnect cycles involving MediaTek Bluetooth devices. Because this is a local kernel memory-safety issue, there may be no durable file-based artifact if exploitation only caused an information leak; absence of logs does not prove non-exploitation. Correlate suspicious kernel events with physical access logs, USB device inventory changes, local login sessions, and recent Bluetooth hardware changes.

• btmtk_usb_hci_wmt_sync
• btmtk_usb
• btmtk
• Bluetooth: btmtk
• MediaTek Bluetooth
• WMT event
• FUNC_CTRL
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: out-of-bounds
• kernel BUG
• Oops:
• Kernel panic
• usbcore: registered new interface driver btmtk_usb

What your security team should do

• Prioritize patching Linux systems that enable Bluetooth, use MediaTek Bluetooth USB hardware, are physically accessible, or allow untrusted local users.
• Deploy the vendor-fixed kernel and reboot affected systems into the updated kernel.
• If patching is delayed, disable Bluetooth and block or blacklist the btmtk_usb driver on systems where Bluetooth is not operationally required.
• Apply physical and logical controls that prevent untrusted USB/Bluetooth devices from being attached to production systems.
• Review kernel logs for recent crashes, KASAN findings, or oops messages involving btmtk, WMT synchronization, or MediaTek Bluetooth initialization.
• Treat suspicious kernel crashes following Bluetooth USB attachment, resume, or reset events as potential exploitation attempts, especially on shared workstations, kiosks, lab systems, or exposed appliances.
• Track distribution advisories for exact fixed kernel package versions because fixed versions were not provided in the input.