CVE-2026-90092 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN
New sk should not be added to parent socket accept queue after last l2cap_sock_cleanup_listen() has run in l2cap_sock_teardown_cb() and state set to BT_CLOSED, as that can result to UAF on dereferencing the dangling parent reference.
l2cap_sock_new_connection_cb() may race with parent l2cap_chan teardown, due to chan->state accessed without consistent locking:
[Task 1] [Task 2]
l2cap_sock_release(parent) l2cap_connect l2cap_sock_shutdown pchan = l2cap_global_chan_by_psm l2cap_chan_lock(pchan) l2cap_chan_close l2cap_sock_teardown_cb pchan->state = BT_CLOSED l2cap_chan_unlock(pchan) ------> l2cap_chan_lock(pchan) l2cap_new_connection l2cap_sock_new_connection_cb l2cap_chan_lock(pchan) <-------- l2cap_chan_unlock(pchan) l2cap_sock_kill(parent) /* bt_sk(sk)->parent dangling */
Fix by adding check for sk_state == BT_LISTEN after acquiring sk lock in l2cap_sock_new_connection_cb(). Add lock_sock() around sk_state writes where missing, to avoid data races.
Although the data races on pchan->state should be fixed too, this defensive sk_state check probably makes sense in any case.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel Bluetooth subsystem contains a critical race condition vulnerability within the L2CAP (Logical Link Control and Adaptation Protocol) implementation that can lead to use-after-free errors. This flaw arises from improper synchronization during socket state transitions, specifically when handling new connection requests against teardown operations of parent channels. The core issue lies in the interaction between l2cap_sock_new_connection_cb(), which processes incoming connections, and l2cap_sock_teardown_cb(), which handles channel cleanup. When a parent socket is released or shut down, it may transition to a closed state while concurrent tasks are still attempting to establish new child sockets based on that same parent reference. Without strict locking mechanisms around critical state checks, the kernel can dereference memory structures that have already been freed by the teardown process.
The technical root cause involves a data race where l2cap_sock_new_connection_cb() accesses and modifies socket states without holding the appropriate locks consistently with other threads performing teardown operations. Specifically, Task 1 may initiate l2cap_sock_release or shutdown on the parent channel while simultaneously Task 2 is executing l2cap_connect followed by l2cap_global_chan_by_psm to locate an existing channel. If Task 2 then proceeds through l2cap_chan_close and triggers l2cap_sock_teardown_cb, it sets the state to BT_CLOSED and potentially frees resources. However, if Task 1 subsequently calls l2cap_new_connection or l2cap_sock_new_connection_cb without verifying that the parent socket is still in a valid listening state, it may attempt to add a new socket to an accept queue associated with a dangling pointer. This results in accessing freed memory when dereferencing the parent reference, leading to potential kernel crashes or arbitrary code execution depending on how the corrupted data is utilized by subsequent operations.
The operational impact of this vulnerability includes system instability and potential privilege escalation. A local attacker who can trigger Bluetooth L2CAP connection attempts while a parent socket is being closed could exploit this race condition to cause a use-after-free scenario. This type of memory corruption allows for reading sensitive kernel memory, crashing the system through a denial-of-service attack, or potentially executing arbitrary code with kernel privileges if the freed memory region has been reallocated and controlled by an attacker. The vulnerability affects systems relying on Bluetooth Low Energy (BLE) or classic Bluetooth L2CAP services where rapid connection establishment and teardown cycles occur frequently, such as in IoT devices or mobile operating environments handling multiple concurrent connections.
To mitigate this risk, the fix implements a defensive check within l2cap_sock_new_connection_cb() to verify that the socket state is BT_LISTEN after acquiring the socket lock before adding new sockets to the accept queue. This ensures that only valid, active listening sockets can spawn child connections. Additionally, developers have added lock_sock() calls around sk_state writes where they were previously missing, ensuring data consistency across concurrent threads. While fixing the underlying race conditions on pchan->state access is also recommended for long-term robustness, this immediate patch provides a critical safeguard against dereferencing dangling pointers during teardown sequences. System administrators should apply kernel updates that include these patches to restore secure Bluetooth operation and prevent exploitation of this synchronization flaw in production environments.