CVE-2026-53357
Beschrijving NL
In de Linux kernel is de volgende kwetsbaarheid verholpen:
Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del()
bt_accept_dequeue() ontkoppelt een nog niet geaccepteerd kind van de ouder
wachtrij accepteren en_sock()s loslaten voordat ze terugkeren, zodat de geretourneerde
sk heeft geen bellerreferentie en is ontgrendeld. l2cap_sock_cleanup_listen() loopt deze kinderen op luistercontact
sluiten. Een gelijktijdige HCI-ontkoppeling drijft hci_rx_work aan ->
l2cap_conn_del() met l2cap_chan_del() + l2cap_sock_kill() en
bevrijdt de kind-sk en zijn l2cap_chan; cleanup_listen() gebruikt dan beide:
BUG: KASAN: slab-use-after-free in l2cap_sock_kill
l2cap_sock_kill / l2cap_sock_cleanup_listen / __x64_sys_close
Bevrijd door: l2cap_conn_del -> l2cap_sock_close_cb -> l2cap_sock_kill
Dit is anders dan de twee fixes die al op dit gebied zijn: commit
e83f5e24da741 ("Bluetooth : serialize accept_q access") serialiseert de
accept_q lijst/poll en neemt tijdelijke refs in bt_accept_dequeue(),
en CVE-2025-39860 serialiseert de gebruikersruimte close()/accept() race by
aanroepen van cleanup_listen() onder lock_sock() in l2cap_sock_release(). Geen van beide dekt l2cap_conn_del() die wordt uitgevoerd vanuit hci_rx_work, dus dit UAF
nog steeds reproduceert op de huidige bluetooth/master. Neem de referentie bij de bron: bt_accept_dequeue() does sock_hold()
terwijl sk nog steeds vergrendeld is, vóór release_sock(); callers sock_put(). cleanup_listen() pint het chan met l2cap_chan_hold_unless_zero() onder
een kort kinderslot (serialisatie vs l2cap_sock_teardown_cb()), druppels
het voor l2cap_chan_lock(), en slaat een dubbele l2cap_sock_kill() over op
SOCK_DEAD. conn->lock wordt hier niet genomen: cleanup_listen() loopt onder
het ouder sk slot en dat zou omkeren
conn->lock -> chan->lock -> sk_lock (lockdep). KASAN/SMP: een onbevoorrechte luister/sluit vs HCI-disconnect race geproduceerd
12 use-after-free rapportages per run voor deze wijziging; 0, en geen lockdep
rapport hebben meer dan 1600+ iteraties erna geracet op bluetooth/master.
Origineel (Engels) tonen
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.