CVE-2026-99013: Bluetooth: ISO: Reject concurrent BIS listener setup

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: ISO: Reject concurrent BIS listener setup

isosocklisten() drops the socket lock before calling isolistenbis() to preserve the hdev->lock ordering. Two concurrent listen() calls on the same broadcast socket can therefore both observe BTBOUND. Caller A can attach connA and release the locks, then caller B can acquire them and attach connB before A publishes BTLISTEN.

isochanadd() checks whether connB already has a socket, but not whether the socket already has a connection. The second attachment overwrites isopi(sk)->conn, leaking the connA reference and leaving connA->sk intact. Socket teardown follows connB, so later events on connA can cause a stale socket access.

Recheck BTBOUND and require isopi(sk)->conn to be NULL after taking both the HCI device and socket locks in isolistenbis(). The connection check also covers the interval between attachment and publication of BTLISTEN. Reject a competing setup with -EBADFD through the existing unlock path before allocating another connection.

A recorded KASAN report from an instrumented kernel shows:

BUG: KASAN: slab-use-after-free in isosockhold+0x119/0x1f0 Call Trace: isosockhold+0x119/0x1f0 isoconndel+0xe4/0x270 hcidisconncompleteevt+0x351/0x8c0 hcieventpacket+0x71b/0xb20 hcirxwork+0x293/0x730

Allocated by task 93: skprotalloc+0x113/0x220 skalloc+0x2b/0x6d0 btsockalloc+0x29/0x370 isosockalloc.constprop.0+0x19/0x300 isosockcreate+0x94/0x100

Freed by task 93: kfree+0x121/0x3c0 skdestruct+0x42b/0x540 isosockrelease+0x29d/0x340 sockrelease+0xa1/0x260 sockclose+0x10/0x20