Cloudanix VulnDB

CVE-2026-99013

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing mistake in Linux Bluetooth handling could let someone already on the computer crash the system or potentially run harmful code.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition in iso_sock_listen() drops socket lock before iso_listen_bis(), allowing two concurrent listen() calls on the same BT_BOUND broadcast socket to both attach connections; the second overwrites iso_pi(sk)->conn without checking for an existing one, leaking the first reference and leaving a stale conn->sk that triggers use-after-free on later hci_disconn_complete_evt or iso_conn_del paths.

Why it matters to the business

Local attackers on affected Linux systems can trigger kernel crashes or potentially escalate privileges via Bluetooth ISO sockets; the flaw is two days old with stable low exploit probability and no known ransomware use, limiting immediate widespread operational disruption but requiring prompt kernel maintenance.

How an attack unfolds

A local attacker creates an ISO broadcast socket, issues two concurrent listen() calls to win the race between BT_BOUND checks and connection attachment, then induces disconnection events so that stale socket references are dereferenced during teardown, producing the observed slab-use-after-free.

How to fix it

Apply the upstream kernel commit that rechecks BT_BOUND state and requires iso_pi(sk)->conn to be NULL after acquiring both the HCI device and socket locks inside iso_listen_bis(); rebuild and reboot with the patched kernel.

How to confirm the fix worked

Confirm the presence of the recheck for BT_BOUND and the NULL conn test in iso_listen_bis(); run the original KASAN reproducer and verify absence of slab-use-after-free reports in iso_sock_hold/iso_conn_del/hci_disconn_complete_evt.

Typical attack path

  1. Obtain local user access on a Linux host with Bluetooth ISO support
  2. Allocate and bind an ISO broadcast socket
  3. Issue two concurrent listen() system calls on the same socket
  4. Trigger HCI disconnection events to exercise the stale conn->sk path
  5. Observe or exploit the resulting use-after-free in iso_sock_hold or iso_conn_del

How to detect it

Search kernel logs and dmesg for KASAN slab-use-after-free reports with stack traces containing iso_sock_hold, iso_conn_del, hci_disconn_complete_evt, or hci_rx_work; correlate with processes performing rapid ISO socket listen operations.

What your security team should do

  • Prioritize kernel updates on all multi-user or Bluetooth-enabled Linux systems within standard patch windows
  • Add kernel log monitoring for KASAN or BUG reports mentioning iso_sock_hold or hci_disconn_complete_evt
  • Where feasible, restrict untrusted local accounts from accessing Bluetooth sockets via LSM or seccomp policies

The record

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Reject concurrent BIS listener setup iso_sock_listen() drops the socket lock before calling iso_listen_bis() to preserve the hdev->lock ordering. Two concurrent listen() calls on the same broadcast socket can therefore both observe BT_BOUND. Caller A can attach connA and release the locks, then caller B can acquire them and attach connB before A publishes BT_LISTEN. __iso_chan_add() checks whether connB already has a socket, but not whether the socket already has a connection. The second attachment overwrites iso_pi(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 BT_BOUND and require iso_pi(sk)->conn to be NULL after taking both the HCI device and socket locks in iso_listen_bis(). The connection check also covers the interval between attachment and publication of BT_LISTEN. 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 iso_sock_hold+0x119/0x1f0 Call Trace: iso_sock_hold+0x119/0x1f0 iso_conn_del+0xe4/0x270 hci_disconn_complete_evt+0x351/0x8c0 hci_event_packet+0x71b/0xb20 hci_rx_work+0x293/0x730 Allocated by task 93: sk_prot_alloc+0x113/0x220 sk_alloc+0x2b/0x6d0 bt_sock_alloc+0x29/0x370 iso_sock_alloc.constprop.0+0x19/0x300 iso_sock_create+0x94/0x100 Freed by task 93: kfree+0x121/0x3c0 __sk_destruct+0x42b/0x540 iso_sock_release+0x29d/0x340 __sock_release+0xa1/0x260 sock_close+0x10/0x20

Affected packages

Ecosystem Package Introduced Fixed