CVE-2026-99009 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex
An RFCOMM connect() issued while a BR/EDR link is being authenticated makes lockdep report a circular dependency, and the reported cycle is a real AB/BA between rfcomm_mutex and hdev->lock.
rfcomm_security_cfm() is called from the HCI event path, which already holds hdev->lock:
hci_rx_work() hci_event_packet() hci_cc_read_enc_key_size() [hdev->lock]
hci_encrypt_cfm() [hci_cb_list_lock]
rfcomm_security_cfm() [rfcomm_mutex]
while an RFCOMM connect() from userspace takes the same two locks the other way round:
rfcomm_sock_connect() rfcomm_dlc_open() [rfcomm_mutex]
__rfcomm_dlc_open() rfcomm_session_create() kernel_connect() l2cap_sock_connect() l2cap_chan_connect() [hdev->lock]
WARNING: possible circular locking dependency detected kworker/u131:1/1128 is trying to acquire lock: rfcomm_mutex, at: rfcomm_security_cfm+0x31/0x3e0 [rfcomm]
but task is already holding lock: hci_cb_list_lock, at: hci_cc_read_enc_key_size+0x1d2/0xcc0 Chain exists of: rfcomm_mutex --> &hdev->lock --> hci_cb_list_lock
hci_auth_complete_evt() and hci_encrypt_change_evt() reach the callback the same way.
Both orders have to be seen in the same boot, which is why a BR/EDR connection alone is not enough to show it: a session set up by the remote side is created by rfcomm_accept_connection() in krfcommd, which calls kernel_accept() and never takes hdev->lock under rfcomm_mutex. Connecting a device that authenticates and encrypts the link and then calling connect() on an RFCOMM socket towards any address - the connect does not have to succeed, the order is recorded before the page timeout - reports it every time.
Only the session socket has to be connected with the lock held, and it does not: nothing else can see the socket before it is put on the session list. So connect it first and take rfcomm_mutex afterwards, which removes the rfcomm_mutex -> hdev->lock order for good, rather than keeping the HCI event path out of rfcomm_mutex.
rfcomm_session_create() becomes rfcomm_session_connect(), which returns the connected socket without touching the session list, and rfcomm_dlc_open() adds the session once it holds the lock again. If another opener added a session for the same pair while this socket was connecting, that session is used and this socket is dropped. __rfcomm_dlc_open() now takes the session it should use, and its state check runs after the lock is re-acquired, so a DLC that was opened or closed in the meantime is still handled.
Over an existing ACL link the connection can complete before the session reaches the list, and the wakeup from the socket callback is then lost, so krfcommd is woken once the session is visible.
Connecting without the lock opens a window in which the socket can be closed. The DLC is not on a session yet, so rfcomm_dlc_close() finds nothing to do and returns without touching it, and rfcomm_dlc_open() would then attach a DLC whose owner is gone. rfcomm_dlc_close() now marks such a DLC with RFCOMM_CLOSED, and rfcomm_dlc_open() checks the mark once it holds rfcomm_mutex again and drops the socket instead of attaching the DLC. The mark is cleared when an open starts, so a DLC that is reused is not affected. This covers both callers of rfcomm_dlc_open(), the socket and the tty layer.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel Bluetooth subsystem contains a concurrency vulnerability within the Radio Frequency Communication (RFCOMM) protocol implementation involving a circular locking dependency between rfcomm_mutex and hdev->lock. This issue manifests as a lockdep warning indicating an AB/BA deadlock scenario when an RFCOMM connect operation is issued while a BR/EDR link authentication or encryption process is ongoing. The vulnerability arises from inconsistent lock ordering across different execution paths within the kernel. Specifically, the HCI event path, triggered by hardware events such as authentication completion or encryption changes, acquires hdev->lock first and subsequently rfcomm_mutex when invoking rfcomm_security_cfm(). In contrast, a userspace application initiating an RFCOMM connection via socket connect() operations follows the reverse order, acquiring rfcomm_mutex before attempting to acquire hdev->lock during lower-layer L2CAP channel establishment. This inversion of lock acquisition order creates a potential deadlock condition if both paths execute concurrently on the same Bluetooth device structure.
The technical flaw is rooted in the synchronization mechanism used to protect RFCOMM session state and HCI device structures. The rfcomm_mutex protects the global list of RFCOMM sessions, while hdev->lock guards data specific to individual Bluetooth devices. When a remote side initiates an RFCOMM session through krfcommd using kernel_accept(), it does not hold rfcomm_mutex during the initial connection setup, which previously masked this issue in many scenarios. However, when a local device connects to a peer that is simultaneously undergoing link authentication and encryption, the conflicting lock orders can lead to a deadlock where each thread holds one lock while waiting for the other. This requires specific timing conditions involving both an existing ACL link and active security procedures on the BR/EDR connection to reproduce reliably.
The operational impact of this vulnerability includes potential system hangs or kernel panics due to deadlocked threads, which can disrupt Bluetooth connectivity and affect system stability. Although lockdep detects the issue during development testing, in production environments without debug kernels enabled, the deadlock may result in unresponsive Bluetooth stacks or require manual intervention such as rebooting the device. The flaw affects both socket-based applications and TTY layer interactions with RFCOMM devices, potentially impacting a wide range of services that rely on serial port emulation over Bluetooth.
To mitigate this vulnerability, the kernel developers restructured the connection logic to ensure consistent lock ordering. The session socket is now connected before acquiring rfcomm_mutex, thereby eliminating the possibility of holding rfcomm_mutex while attempting to acquire hdev->lock in the userspace-initiated path. This change ensures that all code paths follow a uniform locking hierarchy: first securing device-level locks if necessary for lower-layer operations, and then acquiring mutexes for session management only after those operations are complete or safely deferred. Additionally, new state checks were introduced to handle race conditions where a DLC might be closed while the socket is connecting without holding the lock. These changes prevent attachment of detached DLCs and ensure proper cleanup when sessions are reused or abandoned during connection attempts.
This vulnerability aligns with CWE-833 Lock Inversion, which describes situations where multiple locks are acquired in an inconsistent order leading to deadlocks. From a defense perspective, maintaining strict lock ordering policies across all code paths accessing shared resources is critical for preventing such concurrency issues. The fix demonstrates the importance of analyzing cross-path synchronization requirements rather than focusing solely on individual function-level locking strategies. Security practitioners should ensure systems running affected kernel versions are updated with patches that implement these restructured connection sequences to restore robustness against deadlock scenarios in Bluetooth subsystems.