GHSA-MF4H-HFV8-F4V4

Vulnerability from github – Published: 2026-07-02 15:32 – Updated: 2026-07-02 15:32
VLAI?
Details

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.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-53357"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-02T15:17:03Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del()\n\nbt_accept_dequeue() unlinks a not-yet-accepted child from the parent\naccept queue and release_sock()s it before returning, so the returned\nsk has no caller reference and is unlocked.\n\nl2cap_sock_cleanup_listen() walks these children on listening-socket\nclose.  A concurrent HCI disconnect drives hci_rx_work -\u003e\nl2cap_conn_del() which runs l2cap_chan_del() + l2cap_sock_kill() and\nfrees the child sk and its l2cap_chan; cleanup_listen() then uses both:\n\n  BUG: KASAN: slab-use-after-free in l2cap_sock_kill\n    l2cap_sock_kill / l2cap_sock_cleanup_listen / __x64_sys_close\n  Freed by: l2cap_conn_del -\u003e l2cap_sock_close_cb -\u003e l2cap_sock_kill\n\nThis is distinct from the two fixes already in this area: commit\ne83f5e24da741 (\"Bluetooth: serialize accept_q access\") serialises the\naccept_q list/poll and takes temporary refs inside bt_accept_dequeue(),\nand CVE-2025-39860 serialises the userspace close()/accept() race by\ncalling cleanup_listen() under lock_sock() in l2cap_sock_release().\nNeither covers l2cap_conn_del() running from hci_rx_work, so this UAF\nstill reproduces on current bluetooth/master.\n\nTake the reference at the source: bt_accept_dequeue() does sock_hold()\nwhile sk is still locked, before release_sock(); callers sock_put().\ncleanup_listen() pins the chan with l2cap_chan_hold_unless_zero() under\na brief child sk lock (serialising vs l2cap_sock_teardown_cb()), drops\nit before l2cap_chan_lock(), and skips a duplicate l2cap_sock_kill() on\nSOCK_DEAD.  conn-\u003elock is not taken here: cleanup_listen() runs under\nthe parent sk lock and that would invert\nconn-\u003elock -\u003e chan-\u003elock -\u003e sk_lock (lockdep).\n\nKASAN/SMP: an unprivileged listen/close vs HCI-disconnect race produced\n12 use-after-free reports per run before this change; 0, and no lockdep\nreport, over 1600+ raced iterations after it on bluetooth/master.",
  "id": "GHSA-mf4h-hfv8-f4v4",
  "modified": "2026-07-02T15:32:12Z",
  "published": "2026-07-02T15:32:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53357"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/407217734835d21d4e0105ebf347860dc1806f88"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5d86d2f1b4d9a508c441d3e45277ae1a73cfed57"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/751de6ec671fe75ad9cf65a0638d2a06b6a5984d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7eebd4c2c86f573af87ff165d08a83432eb0b919"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/87c543e2f78d0871f271df92dab98901bbd5b6f5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a5ca86a6097a8b030ca3226cd300b17ed330f966"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ab1513597c6cf17cd1ad2a21e3b045421b48e022"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/added1213395071470a900cc845a042fb51882a6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.