← All Advisories
Reported from OT-Advisories.com as of

CVE-2026-53357

Last refreshed2026-10-17

Status: UPDATED  |  Advisory ID: CVE-2026-53357

Key Details

CVECVE-2026-53357
CVSS Score / Version
8.0 (High) / CVSS v3.1
Updated2026-10-16
CVSS Vector
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Prose
attack vector is adjacent; attack complexity is low; privileges required is low; user interaction is none; scope is unchanged; confidentiality impact is high; integrity impact is high; availability impact is high.
Affected products
Linux Kernel
Classified as
CWE-416 (Use After Free)

Affected Products, Subsystems & Sectors

VendorProductAffected VersionsPatch Status
LinuxLinux Kernel
SubsystemsOT Supporting Infrastructure
SectorsAll Sectors

What to Know

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. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References

SourceReference
NVDhttps://nvd.nist.gov/vuln/detail/CVE-2026-53357
CVEhttps://www.cve.org/CVERecord?id=CVE-2026-53357
Report compilation © 2026 OT-Advisories.com  ·  CC BY 4.0  ·  Source materials remain the property of their respective publishers as cited.