---
id: "CVE-2026-99013"
kind: "vulnerability"
aliases: ["CVE-2026-99013"]
title: "Linux kernel: concurrent Bluetooth BIS listen calls cause use-after-free"
severity: "unknown"
cvss: null
epss: 0.00209
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["bluetooth", "kernel", "linux", "runtime", "self-hosted"]
not_affected_if: ["bluetooth-disabled", "no-bluetooth-hardware"]
published_at: "2026-10-23T13:17:24+00:00"
first_seen_at: "2026-10-23T21:57:33+00:00"
updated_at: "2026-10-25T12:38:50+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99013", "first_seen_at": "2026-10-23T21:57:33+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-99013", "first_seen_at": "2026-10-25T12:38:50+00:00"}]
---

# Linux kernel: concurrent Bluetooth BIS listen calls cause use-after-free

Two simultaneous listen() calls on the same Bluetooth ISO broadcast socket can attach two connections, leaving one connection pointing at a socket that is later freed. The sources show a KASAN slab-use-after-free in the Bluetooth ISO connection teardown path, which can crash the kernel or corrupt memory.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- `uname -r` and compare against the kernel version that carries the upstream fix, which the sources do not name
- `lsmod | grep -i bluetooth` to see whether the Bluetooth stack with ISO support is loaded on the host
- unknown whether the sources list a specific config option to test for

## Fix

- Install the kernel update from your distribution that includes the upstream commit 'Bluetooth: ISO: Reject concurrent BIS listener setup' (version unknown from sources)
- Reboot into the patched kernel after updating
- Until patched, unknown whether unloading the Bluetooth ISO modules is a viable mitigation

## Timeline

- 2026-10-23T21:57:33+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99013
- 2026-10-25T12:38:50+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-99013

## From the sources

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

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_