Skip to main content
VulnerabilityPublished Updated

CVE-2026-53357: Linux kernel · Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del()

Source GCVE Database

0

Mentioned vulnerabilities

Authoritative record:CVE-2026-53357· High 8.0

Not known to be exploited · CVSS 8.0 High · fixed in added1213395071470a900cc845a042fb51882a6 : patch Linux kernel soon.

Data as of 26 Oct 2026, 13:47 UTC

CVSS 3.1 base score
8.0High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.3% chance of exploitation in 30 days – higher than 26% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in added1213395071470a900cc845a042fb51882a6, ab1513597c6cf17cd1ad2a21e3b045421b48e022, a5ca86a6097a8b030ca3226cd300b17ed330f966 +5
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 2 Jul 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 15f02b91056253e8cdc592888f431da0731337b8, < added1213395071470a900cc845a042fb51882a6
Fixed in
  • added1213395071470a900cc845a042fb51882a6
LinuxLinuxAffected
  • ≥ 15f02b91056253e8cdc592888f431da0731337b8, < ab1513597c6cf17cd1ad2a21e3b045421b48e022
Fixed in
  • ab1513597c6cf17cd1ad2a21e3b045421b48e022
LinuxLinuxAffected
  • ≥ 15f02b91056253e8cdc592888f431da0731337b8, < a5ca86a6097a8b030ca3226cd300b17ed330f966
Fixed in
  • a5ca86a6097a8b030ca3226cd300b17ed330f966
LinuxLinuxAffected
  • ≥ 15f02b91056253e8cdc592888f431da0731337b8, < 407217734835d21d4e0105ebf347860dc1806f88
Fixed in
  • 407217734835d21d4e0105ebf347860dc1806f88
LinuxLinuxAffected
  • ≥ 15f02b91056253e8cdc592888f431da0731337b8, < 751de6ec671fe75ad9cf65a0638d2a06b6a5984d
Fixed in
  • 751de6ec671fe75ad9cf65a0638d2a06b6a5984d
LinuxLinuxAffected
  • ≥ 15f02b91056253e8cdc592888f431da0731337b8, < 87c543e2f78d0871f271df92dab98901bbd5b6f5
Fixed in
  • 87c543e2f78d0871f271df92dab98901bbd5b6f5

Description

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.

References

Community reviews

Loading reviews…