CVE-2024-50044 in Linux
Summary
by MITRE • 10/21/2024
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change
rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace:
====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline]
ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73
but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 03/23/2026
This vulnerability represents a critical deadlock condition in the Linux kernel's Bluetooth RFCOMM implementation that stems from improper lock ordering and concurrent access patterns. The issue occurs within the rfcomm_sk_state_change function which attempts to acquire a socket lock while another lock is already held by the same execution context. This circular dependency creates a situation where the kernel thread becomes indefinitely blocked, unable to progress through its execution path. The vulnerability specifically affects the Bluetooth protocol stack's handling of RFCOMM socket state changes, which are fundamental operations for managing Bluetooth serial connections and data transfer between devices.
The technical flaw manifests when rfcomm_sock_ioctl function attempts to lock the socket lock while rfcomm_sk_state_change is already executing with that same lock acquired. This creates a classic circular dependency scenario where the kernel's locking subsystem detects the problematic pattern and generates the warning message indicating potential deadlock conditions. The underlying issue is rooted in the improper synchronization between different kernel components that handle Bluetooth RFCOMM operations, particularly around socket state management and device closure operations. This represents a violation of proper lock ordering principles that are fundamental to kernel stability and prevents the system from maintaining consistent state during concurrent Bluetooth operations.
The operational impact of this vulnerability is severe as it can lead to complete system hang or deadlock conditions in Bluetooth-enabled systems, particularly affecting devices that rely heavily on Bluetooth RFCOMM connections for serial communication. When the deadlock occurs, the kernel thread that manages the Bluetooth socket state becomes unresponsive, potentially causing the entire system to freeze or require manual intervention. This vulnerability affects any Linux system running kernel versions that include the affected RFCOMM implementation, making it particularly concerning for embedded systems, IoT devices, and servers that depend on reliable Bluetooth connectivity. The issue can be triggered through normal Bluetooth operations involving socket manipulation and device state changes, making it a latent threat that may not be immediately apparent during routine system operation.
Mitigation strategies should focus on implementing proper lock ordering protocols and ensuring that rfcomm_sk_state_change function does not attempt to acquire locks that are already held by the calling context. The fix requires modifying the kernel code to ensure that socket lock acquisition occurs only when appropriate and that proper lock hierarchy is maintained throughout the RFCOMM subsystem. System administrators should ensure their kernel is updated to the patched version that resolves this circular dependency issue. Additionally, monitoring for lock dependency warnings and implementing proper system resource management can help detect and prevent similar issues. This vulnerability aligns with CWE-362 which describes concurrent execution using shared resource vulnerabilities, and may be related to ATT&CK technique T1070.006 for indicator removal through kernel manipulation. Organizations should also consider implementing robust kernel monitoring and alerting systems to detect potential deadlock conditions in real-time, particularly in mission-critical systems where Bluetooth connectivity is essential for operations.