CVE-2026-64409

What it actually does

This is a Linux kernel denial-of-service flaw in the MediaTek SDIO Bluetooth driver, btmtksdio. A timeout check in btmtksdio_txrx_work() is logically inverted: once the intended 5-second limit expires, the loop condition can become permanently true instead of terminating. When triggered, the worker can spin indefinitely and fail to release the SDIO host, causing blocked kernel worker tasks, hung Bluetooth open/flush operations, and possible degradation of other SDIO-dependent functionality. The impact is availability-focused; the description does not indicate memory corruption, privilege escalation, or data disclosure.

Why it matters to the business

Systems using affected Linux kernels with MediaTek SDIO Bluetooth hardware can experience Bluetooth outages, hung kernel tasks, degraded device responsiveness, or service disruption requiring driver reset or reboot. The risk is highest for embedded, mobile, kiosk, IoT, and edge devices where Bluetooth and SDIO peripherals are operationally important. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no reported exploit maturity, so remediation should be prioritized for exposed or operationally critical affected hardware rather than treated as an internet-scale emergency.

How an attack unfolds

An attacker or fault condition must cause the btmtksdio driver to enter its transmit/receive worker path with interrupt status activity that keeps the loop active until the intended timeout expires. Because the timeout condition is incorrectly combined with the interrupt condition, expiration of the timeout makes the loop continue forever instead of stopping. The worker then never releases the SDIO host, and later Bluetooth operations such as device open, flush, or reset can block behind the stuck work item. In practical terms, exploitation would most likely involve local or near-device interaction with the Bluetooth subsystem, repeated Bluetooth state changes, or a malicious/unreliable Bluetooth/SDIO interaction pattern; there is no indication of a public weaponized exploit or remote code execution capability.

How to fix it

Upgrade to a Linux kernel version or vendor-maintained kernel package that includes the upstream fix for the btmtksdio_txrx_work() loop termination condition. Because no specific fixed versions were provided, use the distribution, device-vendor, or kernel-stable advisory for the relevant platform and verify that the Bluetooth btmtksdio fix has been backported. Where immediate patching is not possible, reduce exposure by disabling unused Bluetooth functionality, blacklisting or unloading the btmtksdio module if operationally acceptable, disabling Bluetooth radios via platform policy, and limiting untrusted physical or near-field access to affected devices. For embedded products, incorporate the fixed kernel into firmware images and regression-test Bluetooth open, close, pairing, scanning, suspend/resume, and reset workflows.

How to confirm the fix worked

Confirm whether systems load or include the btmtksdio driver by checking loaded modules, kernel configuration, hardware inventory, and boot logs for MediaTek SDIO Bluetooth support. Validate remediation by confirming the running kernel package contains the vendor fix or by mapping the kernel build to the patched advisory. Functional validation should include repeated Bluetooth enable/disable, scan, pair, suspend/resume, and interface reset operations while monitoring dmesg or journal logs for hung kernel tasks involving btmtksdio_txrx_work(), btmtksdio_flush(), hci_dev_open_sync(), or kworker blockage. A fixed system should not show persistent btmtksdio worker loops, blocked tasks exceeding the hung-task threshold, or SDIO host lock symptoms during these tests.

Typical attack path

1. Identify a Linux-based device using the MediaTek SDIO Bluetooth driver btmtksdio.
2. Trigger Bluetooth activity or device state transitions that schedule btmtksdio_txrx_work().
3. Keep or induce pending interrupt status activity long enough for the intended 5-second timeout to expire.
4. The flawed loop condition becomes permanently true after timeout expiration.
5. btmtksdio_txrx_work() spins indefinitely and does not release the SDIO host.
6. Subsequent Bluetooth operations, such as btmtksdio_flush() or hci_dev_open_sync(), block or hang.
7. The affected system experiences Bluetooth service outage, hung kernel workers, degraded responsiveness, or requires reboot/recovery.

How to detect it

To assess whether this was already triggered, review kernel logs from dmesg, journald, syslog, serial console captures, crash dumps, and device health telemetry for hung tasks or workqueue stalls involving btmtksdio. Key artifacts include messages showing kworker tasks blocked for more than the hung-task threshold, stack traces containing btmtksdio_flush(), btmtksdio_txrx_work(), hci_dev_open_sync(), cancel_work_sync(), or __cancel_work_timer(), and recurring Bluetooth open/reset failures around the same time. Correlate these events with Bluetooth enable/disable actions, pairing/scanning activity, suspend/resume events, rfkill changes, firmware reloads, or physical/near-field access to the device. Attribution to malicious exploitation is difficult because the same symptoms can result from driver/hardware faults; look for repeated, timed triggering patterns or activity coinciding with untrusted access. There are no known network payload signatures for this issue based on the provided information.

• btmtksdio_txrx_work
• btmtksdio_flush
• hci_dev_open_sync
• __cancel_work_timer
• cancel_work_sync
• INFO: task kworker
• blocked for more than 122 seconds
• blocked for more than
• Bluetooth: btmtksdio
• /sys/module/btmtksdio
• btmtksdio

What your security team should do

• Inventory Linux devices for MediaTek SDIO Bluetooth hardware and the btmtksdio driver, prioritizing embedded, mobile, kiosk, IoT, and edge deployments.
• Patch affected systems using the appropriate distribution or device-vendor kernel update once available, and verify the fix is present in the running kernel, not just installed on disk.
• If patching is delayed, disable Bluetooth or blacklist btmtksdio on systems where Bluetooth is not required.
• Monitor kernel logs for btmtksdio-related hung tasks and correlate with Bluetooth resets, user-reported outages, or repeated radio state changes.
• For products or appliances, request fixed firmware from the vendor and validate that the kernel includes the upstream btmtksdio timeout correction.
• Treat observed exploitation as availability-impacting unless additional evidence indicates separate compromise; this flaw alone does not imply code execution or data theft.
• Because the CVE is not KEV-listed, not ransomware-associated, and has low EPSS, prioritize remediation based on hardware presence and operational criticality rather than broad internet exposure.