CVE-2026-99239

Read full description

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.

CVSS 7.8 (HIGH)

Attention and evidence

HYPE SCORE

0.0/10

REALITY · THREAT PRIORITY

2.7/10

General review priority; not probability

Evidence confidence: Insufficient evidence

Why this priority?

Technical severity: CVSS 7.8: +2.73
Fresh EPSS: 0.13%: +0.00

General review priority, not probability, victim count or asset-specific risk. A range covers missing CVSS/EPSS inputs within the current evidence state.

Sources: 1 documents and public datasets.

Hype components

Headline sample (25%)

0/100

Press, 30 days (60%)

0/100

Grounded branding (15%)

0/100

HYPE TOTAL0/100

Sources and documents

Latest Vulnerabilities

Technical advisory · 02 Nov 2026, 16:17 · CVE-2026-99239 - Bluetooth: L2CAP: refuse __l2cap_chan_add if chan already has conn

Score evolution

● Hype ● Reality

━ Hype Score (Perceived) ━ Reality threat priority. Definition changes are not new attacks.

Public exploit evidence

Public exploit entries / repo candidates

Evidence context and dated references

Reality is general threat/review priority, combining observed exploitation, CVSS severity and fresh EPSS. Evidence confidence is separate. This is not calibrated risk, a victim count or an asset-specific assessment. A range reflects missing numeric inputs. Published 6 days ago. Exploitation evidence usually takes weeks to show up: a low reality score can mean there is no data yet, not that the flaw is mild.

Evidence in context

Confidence in exploitation evidence: Insufficient evidence
Priority basis: Exploitation in attacks unconfirmed; CVSS 7.8; EPSS 0.1%
Attention, last 30 days: 0 distinct story titles; 0 press documents; 0 publisher domains.
Technical potential: local access, low privileges, no user interaction.
Observed activity: No exploitation observation is recorded.
Known scale: Not quantified.
Evidence confidence basis: Insufficient evidence

Score evaluated: 2026-11-05 14:00:34.806270+00:00 · EPSS snapshot: 2026-11-05T12:03:04Z

Source event timeline

Published

02 Nov 2026, 16:06

Score calculated

05 Nov 2026, 14:00