PT-2026-55234 · Linux · Linux
Publicado
2026-07-02
·
Atualizado
2026-07-02
·
CVE-2026-53357
Nenhuma
Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
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.
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
Identificadores relacionados
Produtos afetados
Linux