HIGH
bluetooth L2CAP AcceptQueue UAF
CVE-2026-90092
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
KernelScan AI7.5HIGH
01Description
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.
02KernelScan AI Analysis
Risk summary
A race condition in the Bluetooth L2CAP socket layer allows an incoming connection to be added to a listening socket's accept queue after that socket has already been torn down and freed. This results in a use-after-free when the child socket dereferences its dangling parent pointer. An attacker within Bluetooth range can trigger this by sending a connection request that races with the local application closing the listening socket, potentially achieving kernel memory corruption.
Vulnerability analysis
When a listening L2CAP socket is closed by a local application, its teardown path marks the socket as closed and cleans up the accept queue. Because of a race in how the underlying channel state is protected, an incoming Bluetooth connection that arrives after teardown starts but before the socket is fully destroyed can still be processed, creating a child socket that points to the parent which is about to be freed. After the parent is freed, that child holds a dangling reference, leading to use-after-free corruption in kernel memory. The fix adds a check that rejects new connections unless the parent is still listening, and adds missing locking around state changes in other paths to close the race. This can be reached by any Bluetooth device in range that sends a connection request timed to race with the local application closing its listening socket; no account or privileges on the target are needed, only that Bluetooth is enabled and an L2CAP listener is present.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 5.10 | 5.10.258 | 5.11 | c47339e169bf |
| 5.15 | 5.15.209 | 5.16 | d4bfa78fd679 |
| 6.1 | 6.1.175 | 6.1.188 | bf61a65c6093 |
| 6.12 | 6.12.88 | 6.12.110 | 2a3a27aaf19b |
| 6.18 | 6.18.30 | 6.18.52 | 87276dc15b55 |
| 6.6 | 6.6.140 | 6.6.157 | 491e4c600179 |
| 7.0 | 7.0.7 | 7.1 | — |
| 7.2 | — | 7.2.6 | — |
| mainline | — | 7.3 | — |
| cip/6.1 | — | 6.1.189-cip61 | bf61a65c6093 |
| cip/6.1-rt | — | 6.1.189-cip61-rt32 | bf61a65c6093 |
| cip/6.12 | — | 6.12.111-cip32 | 2a3a27aaf19b |
04CIP Kernels
State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.
| CIP tree | State |
|---|---|
| cip/6.12 | Fixed in 6.12.111-cip32 |
| cip/6.1 | Fixed in 6.1.189-cip61 |
| cip/6.1-rt | Fixed in 6.1.189-cip61-rt32 |
| cip/5.10 | Affected — no CIP fix yet (latest 5.10.271-cip78) |
| cip/5.10-rt | Affected — no CIP fix yet (latest 5.10.268-cip77-rt34) |