Cloudanix VulnDB

CVE-2026-99239

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Nov 2, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in how Linux manages Bluetooth connections could let someone with local access crash the system or gain higher privileges.

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

What it actually does

Race condition in L2CAP channel addition allows a single l2cap_chan to be linked to l2cap_conn more than once, violating internal invariants and potentially causing memory corruption or crashes during cleanup.

Why it matters to the business

Local attackers on affected Linux systems can potentially escalate privileges or cause denial of service via Bluetooth stack manipulation, impacting system stability and security.

How an attack unfolds

An attacker exploits the TOCTOU race by concurrently calling l2cap_chan_connect and l2cap_sock_bind in a way that bypasses state checks, resulting in a second __l2cap_chan_add call.

How to fix it

Apply the upstream kernel commit that adds explicit invariant checks with WARN_ON_ONCE in __l2cap_chan_add, a pre-check in l2cap_chan_connect, and locking in l2cap_sock_bind to guard chan state.

How to confirm the fix worked

Inspect kernel source for the added state checks and locking around chan->state transitions; recompile and boot-test with concurrent Bluetooth socket operations to confirm absence of double-add.

Typical attack path

  1. Prepare multiple Bluetooth sockets in open state
  2. Race l2cap_sock_bind and l2cap_chan_connect from separate tasks
  3. Trigger duplicate __l2cap_chan_add due to missing state guard
  4. Cause invariant violation leading to corruption on channel cleanup

How to detect it

Review kernel logs for L2CAP channel state warnings or BUG/WARN messages triggered by the new checks; correlate with processes performing rapid socket bind/connect sequences.

What your security team should do

  • Prioritize kernel upgrade on all Bluetooth-enabled Linux hosts
  • Disable Bluetooth kernel modules when not required
  • Enable kernel panic-on-oops and monitor logs for L2CAP state warnings

The record

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.

Affected packages

Ecosystem Package Introduced Fixed