CVE-2026-99239 in Linux
Summary
by MITRE • 11/02/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: refuse __l2cap_chan_add if chan already has conn
l2cap_chan may be linked to l2cap_conn at most once. This is assumed in several places, eg l2cap_chan_del cleanup.
There is a TOCTOU race where the invariant is violated:
[Task 1] [Task 2]
l2cap_chan_connect l2cap_sock_bind l2cap_chan_lock lock_sock l2cap_state_change if (sk->sk_state != BT_OPEN) chan->state = BT_CONNECT l2cap_sock_state_change_cb chan->state = BT_BOUND sk->sk_state = BT_BOUND lock_sock <------------------ release_sock sk->sk_state = BT_CONNECT
l2cap_sock_connect() does not check sk->sk_state, so since chan->state is now BT_BOUND, subsequent connect() ends up with second __l2cap_chan_add.
Explicitly document and check the invariant in __l2cap_chan_add with WARN_ON_ONCE. The only callsite where it could be hit is l2cap_chan_connect, so add pre-check there to avoid relying on chan->state. chan->state read/write is not properly guarded currently so there can be other TOCTOUC problems.
Add l2cap_lock_chan in l2cap_sock_bind() to guard chan->state write.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/02/2026
The Linux kernel Bluetooth subsystem contains a time-of-check-to-time-of-use race condition within the Logical Link Control and Adaptation Protocol layer, specifically affecting channel management operations. This vulnerability arises from improper synchronization when handling L2CAP channels during connection establishment and binding processes. The core issue lies in the assumption that an l2cap_chan structure is linked to its corresponding l2cap_conn object at most once throughout its lifecycle. This invariant is critical for cleanup routines such as l2cap_chan_del, which rely on this single-linkage property to correctly manage resources and prevent memory corruption or state inconsistencies. When this assumption is violated due to concurrent execution paths, the integrity of the Bluetooth stack's internal data structures is compromised, potentially leading to undefined behavior including kernel panics, information leaks, or denial of service conditions for local users with access to Bluetooth sockets.
The technical flaw manifests through a specific race condition involving two distinct tasks operating on the same socket and channel objects without adequate mutual exclusion. In one execution path, Task 1 initiates an L2CAP connection via l2cap_chan_connect while simultaneously holding locks that protect certain state transitions. Concurrently, Task 2 performs a bind operation using l2cap_sock_bind followed by a lock acquisition on the channel structure. This sequence allows Task 2 to modify the socket and channel states independently of Task 1's ongoing connection attempt. Specifically, Task 2 may set the channel state to BT_BOUND while Task 1 is in the process of establishing a connection that expects or results in a different state transition. Because l2cap_sock_connect does not adequately verify the current sk->sk_state before proceeding with channel addition logic, it fails to detect that the channel has already been associated with a connection context by another thread. This oversight permits __l2cap_chan_add to be invoked twice for the same logical channel instance, violating the single-linkage invariant and creating a window where race conditions can corrupt internal kernel data structures.
The operational impact of this vulnerability is significant within the local attack surface. An attacker with the ability to create Bluetooth sockets and trigger concurrent bind and connect operations on the affected system could exploit this race condition to destabilize the kernel. The primary consequence is likely a denial of service, as the violation of internal invariants can lead to crashes or hangs during subsequent cleanup phases when l2cap_chan_del attempts to traverse linked lists that now contain duplicate entries or inconsistent pointers. While direct code execution may be difficult due to the nature of race conditions and memory corruption patterns involved, the reliability impact on network services relying on Bluetooth connectivity is substantial. This vulnerability highlights broader issues with state management in the L2CAP layer where chan->state read and write operations are not consistently guarded by appropriate locking mechanisms, leaving other potential time-of-check-to-time-of-use vulnerabilities open to exploitation under similar concurrent access scenarios.
Mitigation strategies focus on enforcing strict synchronization around channel state modifications and connection establishment procedures. The primary fix involves adding explicit checks within __l2cap_chan_add to detect violations of the single-linkage invariant using WARN_ON_ONCE, which serves both as a runtime safeguard and a diagnostic tool for developers monitoring kernel logs. Furthermore, pre-checks are implemented in l2cap_chan_connect to verify channel state before attempting addition, ensuring that operations proceed only when safe based on current conditions rather than relying solely on potentially stale or concurrently modified state variables. Crucially, the introduction of l2cap_lock_chan within l2cap_sock_bind ensures that writes to chan->state are properly serialized with other critical sections accessing the same data structures. These changes align with best practices for concurrent programming in kernel space by minimizing race windows and ensuring atomicity of compound operations involving shared resources.
From a classification perspective, this vulnerability corresponds to CWE-362, which describes concurrent access resulting in race conditions where software executes actions out of order due to lack of proper synchronization mechanisms like locks or semaphores. The exploitation technique aligns with MITRE ATT&CK tactic TA0004, specifically referencing privilege escalation through local exploits if the crash leads to memory corruption that can be leveraged for arbitrary code execution, though primarily it represents a denial of service vector under TA0005 (Defense Evasion) or TA0008 (Lateral Movement) depending on the specific impact scenario. System administrators should apply kernel updates provided by their distribution vendors as soon as they become available to patch this synchronization flaw in the Bluetooth L2CAP implementation, thereby restoring the integrity of channel management operations and preventing potential system instability caused by concurrent socket state modifications.