cbcvebase.
CVE-2026-53357
published 2026-07-02

CVE-2026-53357: 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()…

PriorityP342high8CVSS 3.1
AVAACLPRLUINSUCHIHAH
EPSS
0.26%
17.4th percentile
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.

Affected

24 ranges
VendorProductVersion rangeFixed in
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel>= 5.11 < 5.15.2105.15.210
linuxlinux_kernel>= 5.16 < 6.1.1756.1.175
linuxlinux_kernel>= 5.7 < 5.10.2595.10.259
linuxlinux_kernel>= 6.13 < 6.18.346.18.34
linuxlinux_kernel>= 6.19 < 7.0.117.0.11
linuxlinux_kernel>= 6.2 < 6.6.1426.6.142
linuxlinux_kernel>= 6.7 < 6.12.926.12.92
ubuntulinux
ubuntulinux-aws
ubuntulinux-azure
ubuntulinux-azure-fde
ubuntulinux-gcp
ubuntulinux-gke
ubuntulinux-hwe-7.0
ubuntulinux-ibm
ubuntulinux-oem-7.0
ubuntulinux-oracle
ubuntulinux-raspi
ubuntulinux-realtime

CVSS provenance

nvdv3.18.0HIGHCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vendor_redhat7.8HIGH
vendor_ubuntu7.0HIGH
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.