CVE-2026-98290 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: avoid socket lock inversion in listener cleanup
rfcomm_sock_cleanup_listen() closes unaccepted child sockets through rfcomm_sock_close(), which takes the child socket lock before rfcomm_dlc_close() acquires rfcomm_mutex. The RFCOMM worker takes these locks in reverse order while handling connections and DLC state changes, so lockdep reports a possible deadlock.
Close dequeued children without taking their socket lock. The accept queue owns a reference to each child, and bt_accept_dequeue() locks the child while unlinking it and clearing its parent pointer.
Dropping the child lock makes it important to prevent a concurrent rfcomm_connect_ind() from enqueueing a new child after cleanup observes an empty queue. Set a listening socket to BT_CLOSED while its lock is still held, before dropping the lock and draining the queue. The state check in rfcomm_connect_ind() then rejects new children once cleanup starts.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/06/2026
The Linux kernel vulnerability identified as CVE-2024-related involves a potential deadlock within the Bluetooth RFCOMM subsystem during listener socket cleanup operations. This issue stems from an inconsistent lock ordering between two distinct code paths that manage resource acquisition for child sockets and global mutexes. Specifically, the function rfcomm_sock_cleanup_listen is responsible for closing unaccepted child sockets by invoking rfcomm_sock_close. This operation attempts to acquire the individual child socket lock before subsequently acquiring the broader rfcomm_mutex within the rfcomm_dlc_close routine. Conversely, when the RFCOMM worker thread processes incoming connections or handles Data Link Connection (DLC) state changes, it acquires these locks in the reverse order: first securing the rfcomm_mutex and then locking the individual child socket. This inversion of lock acquisition sequences creates a classic deadlock scenario where two threads may each hold one resource while waiting for the other, leading to system hangs or unresponsive Bluetooth services. The Linux kernel's lock dependency validator, known as lockdep, is designed to detect such potential deadlocks during runtime testing and development phases, flagging this specific inversion as a critical concurrency flaw that compromises system stability under certain race conditions.
The technical root cause of this vulnerability lies in the synchronization primitives used to protect shared data structures within the RFCOMM implementation. The accept queue for listening sockets contains references to child socket objects representing pending or unaccepted connections. When cleanup is initiated, the existing code path attempts to lock each child socket individually before proceeding with global state changes protected by rfcomm_mutex. However, because other kernel threads handling active DLC states already hold the mutex and seek the socket locks, a circular wait condition emerges. This structural flaw highlights a common challenge in complex kernel subsystems where multiple locking hierarchies intersect without strict adherence to a single canonical order of acquisition. The vulnerability is particularly relevant in high-throughput Bluetooth environments or scenarios involving rapid connection establishment and teardown cycles, where the probability of concurrent execution paths triggering this lock inversion increases significantly.
The operational impact of this deadlock can range from minor performance degradation due to retry loops to severe system instability including kernel panics or complete freezing of the Bluetooth stack. If a user-space application relies on RFCOMM for serial port emulation or other critical communication channels, such as those used in IoT devices or industrial control systems, a deadlock could result in service denial and potential data loss during active sessions. Furthermore, because this is a concurrency bug dependent on timing, it may not manifest consistently under normal load but can be triggered by specific sequences of connection attempts and cancellations, making it difficult to reproduce without specialized stress testing tools like lockdep or KCSAN (Kernel Concurrency Sanitizer). The lack of immediate crash symptoms in some cases might lead developers to overlook the issue until a production environment experiences intermittent hangs that are challenging to diagnose.
To mitigate this vulnerability, the Linux kernel maintainers have implemented a revised approach to handling child socket cleanup that eliminates the need for acquiring individual socket locks during the dequeueing process. The fix leverages the fact that the accept queue already maintains references to each child socket and utilizes bt_accept_dequeue(), which safely handles unlinking and clearing parent pointers while managing necessary locking internally. By dropping the requirement to lock children individually, the code avoids entering into a potential deadlock with threads holding rfcomm_mutex. Additionally, to prevent race conditions where new connections might be enqueued after cleanup has logically started but before it physically completes, the patch introduces a state check mechanism. The listening socket is set to BT_CLOSED while its own lock is still held. This ensures that any concurrent attempt by rfcomm_connect_ind to enqueue a new child connection will observe the closed state and reject the operation immediately. This design change enforces a strict ordering where global mutex operations are decoupled from individual socket locking during cleanup, thereby restoring consistency to the kernel's synchronization model for RFCOMM sockets.
From an industry standards perspective, this vulnerability aligns with CWE-833, which describes Deadlock conditions resulting from improper resource lock management and inconsistent lock ordering. The ATT&CK framework does not directly map internal kernel deadlocks as attack techniques since they are typically unintentional stability issues rather than exploitable vulnerabilities for unauthorized access or privilege escalation in the traditional sense. However, if an attacker can induce high rates of connection churn, they might leverage this deadlock to cause a Denial of Service against Bluetooth-enabled systems. Therefore, while primarily a reliability issue, it falls under the broader category of availability impacts associated with resource management flaws. System administrators and developers should ensure that Linux kernels are updated to versions containing this RFCOMM lock inversion fix. For environments where kernel updates are delayed, monitoring for signs of Bluetooth stack unresponsiveness or analyzing kernel logs for lockdep warnings can serve as early detection mechanisms. The resolution demonstrates the importance of rigorous concurrency testing in network protocol implementations within operating system kernels to prevent subtle synchronization errors that compromise long-term system stability.