HIGH Introduced in 5.7
bluetooth L2CAP CleanupListen UAF
CVE-2026-53357
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
01Description
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del() bt_accept_dequeue() unlinks a not-yet-accepted child from the parent accept queue and release_sock()s it before returning, so the returned sk has no caller reference and is unlocked. l2cap_sock_cleanup_listen() walks these children on listening-socket close. A concurrent HCI disconnect drives hci_rx_work -> l2cap_conn_del() which runs l2cap_chan_del() + l2cap_sock_kill() and frees the child sk and its l2cap_chan; cleanup_listen() then uses both: BUG: KASAN: slab-use-after-free in l2cap_sock_kill l2cap_sock_kill / l2cap_sock_cleanup_listen / __x64_sys_close Freed by: l2cap_conn_del -> l2cap_sock_close_cb -> l2cap_sock_kill This is distinct from the two fixes already in this area: commit e83f5e24da741 ("Bluetooth: serialize accept_q access") serialises the accept_q list/poll and takes temporary refs inside bt_accept_dequeue(), and CVE-2025-39860 serialises the userspace close()/accept() race by calling cleanup_listen() under lock_sock() in l2cap_sock_release(). Neither covers l2cap_conn_del() running from hci_rx_work, so this UAF still reproduces on current bluetooth/master. Take the reference at the source: bt_accept_dequeue() does sock_hold() while sk is still locked, before release_sock(); callers sock_put(). cleanup_listen() pins the chan with l2cap_chan_hold_unless_zero() under a brief child sk lock (serialising vs l2cap_sock_teardown_cb()), drops it before l2cap_chan_lock(), and skips a duplicate l2cap_sock_kill() on SOCK_DEAD. conn->lock is not taken here: cleanup_listen() runs under the parent sk lock and that would invert conn->lock -> chan->lock -> sk_lock (lockdep). KASAN/SMP: an unprivileged listen/close vs HCI-disconnect race produced 12 use-after-free reports per run before this change; 0, and no lockdep report, over 1600+ raced iterations after it on bluetooth/master.
02KernelScan AI Analysis
Risk summary
A local unprivileged user who can open Bluetooth L2CAP sockets can trigger a use-after-free by racing a listening socket close against a concurrent HCI disconnect. The freed child socket and its l2cap_chan are accessed by l2cap_sock_cleanup_listen() after l2cap_conn_del() has already freed them, potentially enabling privilege escalation or kernel memory corruption.
Vulnerability analysis
The root cause is a missing reference count on child sockets dequeued from the Bluetooth accept queue. bt_accept_dequeue() unlinks a child socket from the parent's accept queue and calls release_sock() before returning, leaving the caller with no reference and an unlocked socket. When l2cap_sock_cleanup_listen() iterates over these children during a listening socket close, a concurrent HCI disconnect path (hci_rx_work -> l2cap_conn_del() -> l2cap_chan_del() -> l2cap_sock_kill()) can free the child sk and its l2cap_chan between the dequeue and the cleanup_listen() usage, producing a slab-use-after-free. The fix adds sock_hold() inside bt_accept_dequeue() while the child sk is still locked, before release_sock(), so every caller receives a reference it must drop with sock_put(). Additionally, l2cap_sock_cleanup_listen() is hardened: it briefly takes the child sk lock to fetch and pin the chan via l2cap_chan_hold_unless_zero() (serialising against l2cap_sock_teardown_cb()), then drops the sk lock before taking chan->lock to avoid lock-order inversion, and skips a duplicate l2cap_sock_kill() if SOCK_DEAD is already set. All other cleanup_listen() and accept() callers across iso.c, rfcomm/sock.c, and sco.c are updated to call sock_put() to balance the new reference.
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 5.10 | 5.7 | 5.10.259 | 751de6ec671f |
| 5.15 | 5.7 | 5.15.210 | 407217734835 |
| 6.1 | 5.7 | 6.1.175 | 7eebd4c2c86f |
| 6.12 | 5.7 | 6.12.92 | 87c543e2f78d |
| 6.18 | 5.7 | 6.18.34 | added1213395 |
| 6.6 | 5.7 | 6.6.142 | 5d86d2f1b4d9 |
| 7.0 | 5.7 | 7.0.11 | a5ca86a6097a |
| mainline | 5.7 | 7.1 | ab1513597c6c |