CVE-2026-80914: Bluetooth: ISO: fix use-after-free of listener socket in iso_conn_ready
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: ISO: fix use-after-free of listener socket in isoconnready
isoconnready() looks up the BIS listener socket with isogetsock(), which takes a reference, and then, without re-checking its state, creates a child socket from it:
parent = isogetsock(hdev, ...); if (!parent) return;
locksock(parent); sk = isosockalloc(socknet(parent), NULL, BTPROTOISO, ...); ... isochanadd(conn, sk, parent); ... releasesock(parent); sockput(parent);
If the listener socket is closed concurrently, between isogetsock() and locksock(), the reference taken by isogetsock() may be the last one: the close path drops the link-list reference, and once isoconnready() 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 isochandel() -> btacceptunlink(), 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 isochandel().
Fix it the same way the connected (non-BIS) path was fixed in commit 0d255e63fcf3 ("Bluetooth: ISO: hold sk properly in isoconnready"): after taking the socket lock, re-check that the parent is still a listening, alive socket, and bail out otherwise.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel Bluetooth: ISO fix use-after-free of listener socket in iso_conn_readyto a version that resolves this vulnerability.Patch 0d255e63fcf3
Event History
Frequently Asked Questions
Which deployments are most likely to be exposed?
The affected path involves Bluetooth ISO BIS listener sockets. Systems that do not use this listener path are not described as reaching the vulnerable child-socket linkage.
What timing is required to trigger the dangling parent reference?
The BIS listener socket must be closed concurrently after iso_conn_ready() obtains a reference to it but before it locks the socket. A child socket is then linked to the listener, and a later child disconnect can dereference the freed parent.
Are fixes available for review or backporting?
The supplied references identify stable-tree fixes at commits 2387cd06a2c0b416f05028b02bba1089f54c28d9f54c28d9, 49fd7116f76b860b230843700fb7423ab5331e1f, and 03288b7447c9e572f8ab82fc29cfb4ca719ab210. The provided data does not specify the kernel versions containing those fixes.