---
id: "CVE-2026-99239"
kind: "vulnerability"
aliases: ["CVE-2026-99239"]
title: "Linux kernel: Bluetooth L2CAP race can link a channel twice"
severity: "high"
cvss: 7.8
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["bluetooth", "linux-kernel", "linux-servers", "package"]
not_affected_if: ["bluetooth-disabled", "module-not-loaded", "no-local-users"]
published_at: "2026-11-02T16:17:49+00:00"
first_seen_at: "2026-11-02T16:24:06+00:00"
updated_at: "2026-11-02T16:27:26+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99239", "first_seen_at": "2026-11-02T16:24:06+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-11-02T16:27:26+00:00"}]
---

# Linux kernel: Bluetooth L2CAP race can link a channel twice

A race between Bluetooth socket bind and connect in the Linux kernel can attach one L2CAP channel to a connection twice. The sources do not describe what an attacker can then do beyond crashing or corrupting kernel state.

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

## How to check

- Run `uname -r` and compare with your distro's kernel changelog or advisory for commit 86b55991d3cd ("Bluetooth: L2CAP: refuse __l2cap_chan_add if chan already has conn").
- Check whether Bluetooth is loaded: `lsmod | grep -E 'bluetooth|l2cap'` (L2CAP is part of the bluetooth module). If not loaded and no Bluetooth hardware, you are very unlikely to be exposed.
- Check for the kernel config: `grep CONFIG_BT= /boot/config-$(uname -r)`.

## Fix

Install a kernel that contains upstream commit 86b55991d3cd690e73c5ef8d20b75ae4905b357a. A backport to the 6.1 and 5.10 stable lines was posted on 2026-10-27, but I found no released stable version number yet. Until then, blacklist the bluetooth module if you don't need it.

## Timeline

- 2026-11-02T16:24:06+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99239
- 2026-11-02T16:27:26+00:00 analyst — Read the upstream patch (Pauli Virtanen, 2026-09-02) and the stable backport posting for 6.1/5.10 (Lee Jones, 2026-10-27). Fix is mainline commit 86b55991d3cd690e73c5ef8d20b75ae4905b357a. Bug introduced by b66774b48dd9. No released stable version numbers or affected range found; both documents are patch postings, not release notes, so nothing is marked verified. No exploitation or PoC seen. Attack vector is local (CVSS AV:L). To settle: the stable release notes (kernel.org) or distro advisories listing the first release containing 86b55991d3cd.

## Documents

- [fix] [PATCH 4/4] Bluetooth: L2CAP: refuse __l2cap_chan_add if chan already has conn (Pauli Virtanen, 2026-09-02) https://lists.openwall.net/linux-kernel/2026/09/01/3149
- [fix] [STABLE v6.1-v5.10 2/2] Bluetooth: L2CAP: refuse __l2cap_chan_add (Lee Jones, 2026-10-27) https://lists.openwall.net/linux-kernel/2026/10/27/967

## From the sources

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

Bluetooth: L2CAP: refuse __l2cap_chan_add if chan already has conn

l2cap_chan may be linked to l2cap_conn at most once. This is assumed in
several places, eg l2cap_chan_del cleanup.

There is a TOCTOU race where the invariant is violated:

    [Task 1]                          [Task 2]
    l2cap_chan_connect                l2cap_sock_bind
      l2cap_chan_lock                   lock_sock
      l2cap_state_change                if (sk->sk_state != BT_OPEN)
        chan->state = BT_CONNECT
        l2cap_sock_state_change_cb      chan->state = BT_BOUND
                                        sk->sk_state = BT_BOUND
          lock_sock <------------------ release_sock
          sk->sk_state = BT_CONNECT

l2cap_sock_connect() does not check sk->sk_state, so since chan->state
is now BT_BOUND, subsequent connect() ends up with second
__l2cap_chan_add.

Explicitly document and check the invariant in __l2cap_chan_add with
WARN_ON_ONCE. The only callsite where it could be hit is
l2cap_chan_connect, so add pre-check there to avoid relying on
chan->state. chan->state read/write is not properly guarded currently so
there can be other TOCTOUC problems.

Add l2cap_lock_chan in l2cap_sock_bind() to guard chan->state write.

---

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