Answer in brief
CVE-2026-53357 records a High severity (CVSS 8.0) vulnerability in Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 8.0. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Product | Affected versions | Fixed versions |
|---|---|---|
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:7.1:rc2:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:7.1:rc3:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:7.1:rc4:*:*:*:*:*:* | Not reported | Not reported |
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=15f02b91056253e8cdc592888f431da0731337b8 <751de6ec671fe75ad9cf65a0638d2a06b6a5984d || >=15f02b91056253e8cdc592888f431da0731337b8 <407217734835d21d4e0105ebf347860dc1806f88 || >=15f02b91056253e8cdc592888f431da0731337b8 <7eebd4c2c86f573af87ff165d08a83432eb0b919 || >=15f02b91056253e8cdc592888f431da0731337b8 <5d86d2f1b4d9a508c441d3e45277ae1a73cfed57 || >=15f02b91056253e8cdc592888f431da0731337b8 <87c543e2f78d0871f271df92dab98901bbd5b6f5 || >=15f02b91056253e8cdc592888f431da0731337b8 <added1213395071470a900cc845a042fb51882a6 || >=15f02b91056253e8cdc592888f431da0731337b8 <a5ca86a6097a8b030ca3226cd300b17ed330f966 || >=15f02b91056253e8cdc592888f431da0731337b8 <ab1513597c6cf17cd1ad2a21e3b045421b48e022 | 751de6ec671fe75ad9cf65a0638d2a06b6a5984d, 407217734835d21d4e0105ebf347860dc1806f88, 7eebd4c2c86f573af87ff165d08a83432eb0b919, 5d86d2f1b4d9a508c441d3e45277ae1a73cfed57, 87c543e2f78d0871f271df92dab98901bbd5b6f5, added1213395071470a900cc845a042fb51882a6, a5ca86a6097a8b030ca3226cd300b17ed330f966, ab1513597c6cf17cd1ad2a21e3b045421b48e022 |
| Linux/Linuxgeneric | 5.7 | Not reported |
Published upstream
Jul 2, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jul 2, 2026
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.
Quoted source text, attributed separately from HOL analysis.