CVE-2026-80914
largeUse-after-free in Linux kernel Bluetooth ISO listener handling (iso_conn_ready)
CVE-2026-80914 is a use-after-free in the Linux kernel's Bluetooth ISO (isochronous) subsystem: when a Broadcast Isochronous Stream (BIS) connection becomes ready, iso_conn_ready() looks up the listening socket, but if that socket is closed concurrently the taken reference can be the last one, freeing the socket while the child socket still links to it. A later disconnect of the child then dereferences the dangling parent pointer (bt_accept_unlink / iso_chan_del), corrupting freed kernel memory. An attacker positioned within Bluetooth radio range (adjacent network, per the CVSS 8.8 vector) can trigger the race and potentially achieve kernel memory disclosure, modification, or a crash. Only Linux systems running a kernel with the Bluetooth ISO code and an application listening for ISO/BIS connections (LE Audio) are practically affected. No public proof-of-concept is known and the flaw is not in CISA's KEV, with no confirmed in-the-wild exploitation.
What to do: Track your distribution's kernel updates and install one containing the iso_conn_ready() fix (the same lock-and-recheck approach as commit 0d255e63fcf3 for the connected path). As an interim mitigation, avoid running LE Audio/BIS listener applications or disable Bluetooth on affected hosts, since only systems with an open ISO listener are exposed to the race.
| Linux kernel (Bluetooth ISO subsystem, iso_conn_ready BIS listener path) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: fix use-after-free of listener socket in iso_conn_ready iso_conn_ready() looks up the BIS listener socket with iso_get_sock(), which takes a reference, and then, without re-checking its state, creates a child socket from it: parent = iso_get_sock(hdev, ...); if (!parent) return; lock_sock(parent); sk = iso_sock_alloc(sock_net(parent), NULL, BTPROTO_ISO, ...); ... iso_chan_add(conn, sk, parent); ... release_sock(parent); sock_put(parent); If the listener socket is closed concurrently, between iso_get_sock() and lock_sock(), the reference taken by iso_get_sock() may be the last one: the close path drops the link-list reference, and once iso_conn_ready() drops its own reference at the end of the function the socket is freed. The child socket, however, is already linked to the freed parent, and a later disconnect of the child runs iso_chan_del() -> bt_accept_unlink(), which dereferences the dangling parent pointer into the freed accept queue (a use-after-free). The same dangling pointer is also dereferenced through parent->***() in iso_chan_del(). Fix it the same way the connected (non-BIS) path was fixed in commit 0d255e63fcf3 ("Bluetooth: ISO: hold sk properly in iso_conn_ready"): after taking the socket lock, re-check that the parent is still a listening, alive socket, and bail out otherwise.
- Vector
- CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.