CVE-2026-64409 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()
Every once in a while we see a hung btmtksdio_flush() task:
INFO: task kworker/u17:0:189 blocked for more than 122 seconds. __cancel_work_timer+0x3f4/0x460 cancel_work_sync+0x1c/0x2c btmtksdio_flush+0x2c/0x40 hci_dev_open_sync+0x10c4/0x2190 [..]
It all boils down to incorrect time_is_before_jiffies() usage in btmtksdio_txrx_work(). The btmtksdio_txrx_work() loop is expected to be terminated if running for longer than 5*HZ. However the timeout check is twisted: time_is_before_jiffies(old_jiffies + 5*HZ) evaluates to true when old_jiffies + 5*HZ is in the past i.e. when a timeout has occurred. Using OR with time_is_before_jiffies(txrx_timeout) means that: - before the 5-second timeout: the condition is `int_status || false`, so it loops as long as there are pending interrupts. - after the 5-second timeout: the condition becomes `int_status || true`, which is always true.
When the loop becomes infinite btmtksdio_txrx_work() loop never terminates and never releases the SDIO host.
Fix loop termination condition to actually enforce a 5*HZ timeout.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/25/2026
The vulnerability resides in the Linux kernel's Bluetooth subsystem, specifically within the btmtksdio driver that handles MediaTek SDIO-based Bluetooth devices. This issue manifests as an infinite loop in the btmtksdio_txrx_work() function which leads to system hangs and resource exhaustion. The problem occurs when the Bluetooth device enters a state where it cannot properly process incoming or outgoing data packets, causing the kernel worker thread to become indefinitely blocked. The symptom observed is a kworker thread remaining blocked for extended periods, in this case over 120 seconds, indicating that the normal timeout mechanisms have failed and the system cannot recover from this condition.
The core technical flaw stems from incorrect usage of the time_is_before_jiffies() function within the loop termination logic. This function is designed to compare timestamps and determine if a given time value falls before the current jiffies counter, which represents the system's uptime in kernel tick units. The driver attempts to implement a 5-second timeout mechanism by checking whether old_jiffies + 5*HZ has passed, but the logical implementation is inverted. When the timeout period expires, the condition evaluates incorrectly, causing the loop to continue indefinitely instead of terminating as intended.
The flawed logic creates a pathological condition where the loop behavior changes dramatically after the timeout threshold is reached. Before the timeout, the condition correctly evaluates to false when there are no pending interrupts, allowing the loop to exit properly. However, once the timeout occurs, the OR operation with time_is_before_jiffies(txrx_timeout) causes the entire expression to always evaluate to true, creating an infinite loop. This fundamental error in timeout implementation violates standard operating system design principles and creates a persistent denial of service condition that affects the entire Bluetooth subsystem.
The operational impact of this vulnerability is significant as it can cause complete system hangs or unresponsiveness when Bluetooth devices are actively communicating. Network connectivity may become impaired, and the affected kernel worker thread cannot be properly scheduled to handle other tasks. The SDIO host controller remains indefinitely locked, preventing any further communication with the Bluetooth device until a system reboot occurs. This vulnerability affects systems using MediaTek SDIO-based Bluetooth adapters and represents a critical reliability issue that could be exploited to create persistent denial of service conditions.
The fix requires correcting the timeout logic within the btmtksdio_txrx_work() function to properly implement the intended 5*HZ timeout mechanism. This involves restructuring the conditional statement to ensure that when the timeout period has elapsed, the loop will terminate regardless of interrupt status. The corrected implementation should maintain the existing interrupt handling functionality while ensuring proper timeout enforcement. This modification aligns with standard kernel programming practices for implementing time-based loop termination and prevents the accumulation of system resources in indefinite wait states.
From a cybersecurity perspective, this vulnerability maps to CWE-835: Loop with Unreachable Exit Condition, which describes infinite loops that can occur due to incorrect termination conditions. The issue also relates to ATT&CK technique T1499.004: Endpoint Denial of Service - Application or System Exploitation, as it represents a method for causing system instability through kernel-level resource exhaustion. The vulnerability demonstrates the critical importance of proper timeout implementation in kernel drivers and highlights how subtle logic errors can lead to severe operational impacts. This fix ensures that the Bluetooth subsystem maintains proper resource management and prevents the accumulation of blocked worker threads that could be exploited by malicious actors to create persistent system disruptions.
The resolution addresses the fundamental design flaw in the driver's timeout handling mechanism while preserving all existing functionality for normal Bluetooth operations. Proper validation of time-based conditions in kernel space is essential for maintaining system stability and preventing resource exhaustion attacks. The corrected implementation ensures that all kernel threads properly respect their designated time limits and release system resources appropriately, thereby maintaining the overall reliability and security posture of Linux systems using MediaTek Bluetooth hardware. This vulnerability serves as a reminder of the critical nature of proper timeout handling in real-time systems and the potential for seemingly minor logic errors to cause significant operational impacts.