CVE-2026-53357

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: fix UAF in l2capsockcleanuplisten() vs l2capconn_del()

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

l2capsockcleanuplisten() walks these children on listening-socket close. A concurrent HCI disconnect drives hcirxwork -> l2capconndel() which runs l2capchandel() + l2capsockkill() and frees the child sk and its l2capchan; cleanup_listen() then uses both:

BUG: KASAN: slab-use-after-free in l2capsockkill l2capsockkill / l2capsockcleanup_listen / _x64sysclose Freed by: l2capconndel -> l2capsockclosecb -> l2capsockkill

This is distinct from the two fixes already in this area: commit e83f5e24da741 ("Bluetooth: serialize acceptq access") serialises the acceptq list/poll and takes temporary refs inside btacceptdequeue(), and CVE-2025-39860 serialises the userspace close()/accept() race by calling cleanuplisten() under locksock() in l2capsockrelease(). Neither covers l2capconndel() running from hcirxwork, so this UAF still reproduces on current bluetooth/master.

Take the reference at the source: btacceptdequeue() does sockhold() while sk is still locked, before releasesock(); callers sockput(). cleanuplisten() pins the chan with l2capchanholdunlesszero() under a brief child sk lock (serialising vs l2capsockteardowncb()), drops it before l2capchanlock(), and skips a duplicate l2capsockkill() on SOCKDEAD. conn->lock is not taken here: cleanuplisten() runs under the parent sk lock and that would invert conn->lock -> chan->lock -> sklock (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.