CVE-2024-26886 in Linux
Summary
by MITRE • 04/17/2024
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: af_bluetooth: Fix deadlock
Attemting to do sock_lock on .recvmsg may cause a deadlock as shown bellow, so instead of using sock_sock this uses sk_receive_queue.lock on bt_sock_ioctl to avoid the UAF:
INFO: task kworker/u9:1:121 blocked for more than 30 seconds. Not tainted 6.7.6-lemon #183 Workqueue: hci0 hci_rx_work Call Trace: <TASK> __schedule+0x37d/0xa00 schedule+0x32/0xe0 __lock_sock+0x68/0xa0 ? __pfx_autoremove_wake_function+0x10/0x10 lock_sock_nested+0x43/0x50 l2cap_sock_recv_cb+0x21/0xa0 l2cap_recv_frame+0x55b/0x30a0 ? psi_task_switch+0xeb/0x270 ? finish_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 process_one_work+0x13a/0x2f0 worker_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe0/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK>
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 06/01/2026
The vulnerability CVE-2024-26886 represents a critical deadlock condition within the Linux kernel's Bluetooth implementation, specifically affecting the af_bluetooth subsystem. This issue manifests when attempting to acquire socket locks during receive message operations, creating a circular dependency that can lead to system-wide hangs. The flaw occurs in the bt_sock_ioctl function where the kernel attempts to use sock_lock on .recvmsg operations, which creates an improper locking sequence that prevents normal system operation. The deadlock scenario described in the kernel logs shows a worker thread blocked for over 30 seconds, indicating a severe operational impact that can render Bluetooth functionality non-responsive and potentially cause system instability.
The technical root cause of this vulnerability lies in improper lock ordering and concurrent access patterns within the Bluetooth socket implementation. When the kernel attempts to acquire locks during socket operations, it creates a situation where the lock acquisition sequence becomes circular, preventing any further progress in the system. The specific call trace reveals that the deadlock originates from hci_rx_work processing, where l2cap_sock_recv_cb and l2cap_recv_frame functions attempt to acquire socket locks that are already held by other threads. This pattern creates a classic deadlock condition that is particularly dangerous in real-time systems where Bluetooth connectivity is critical for device operation. The vulnerability operates at the kernel level, making it particularly severe as it can affect the entire system stability rather than just individual applications.
From a cybersecurity perspective, this vulnerability presents significant operational risks as it can be exploited to cause denial of service conditions in Bluetooth-enabled systems. The deadlock scenario can be triggered through normal Bluetooth socket operations, making it particularly concerning for embedded systems, mobile devices, and IoT platforms that rely heavily on Bluetooth connectivity. The vulnerability affects the Linux kernel's Bluetooth subsystem and can be classified under CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and CWE-367 (Time-of-Check Time-of-Use). The operational impact extends beyond simple service disruption as the deadlock can cause cascading failures in system components that depend on Bluetooth functionality, potentially leading to complete system hangs in worst-case scenarios.
The mitigation strategy for this vulnerability involves applying the kernel patch that modifies the locking mechanism in bt_sock_ioctl to use sk_receive_queue.lock instead of the problematic sock_sock approach. This change ensures proper lock ordering and prevents the circular dependency that leads to deadlock conditions. System administrators should prioritize updating their kernel versions to include this fix, particularly in environments where Bluetooth connectivity is critical for operations. The patch implementation aligns with ATT&CK technique T1499.001 (Network Denial of Service) as it addresses a potential method of causing system unresponsiveness through improper resource management. Organizations should also implement monitoring systems to detect unusual worker thread blocking patterns that might indicate similar locking issues in other kernel subsystems, as this vulnerability demonstrates the importance of proper lock ordering in kernel-level programming.