Skip to main content
No exploitation reportedAwaiting NVD analysis

CVE-2026-99239

Bluetooth: L2CAP: refuse __l2cap_chan_add if chan already has conn

No exploitation reported by the sources we read.

  • Published2026-11-02

Am I affected?

With a domain, we read the version its public headers and pages expose. A distribution build can carry the fix under an older number.

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.

Timeline

dates in UTC
  1. 2026-11-0216:06CVE publishedCNA

Observed activity

isMalicious corpus · updated 2026-11-02 15:37 UTC
Indicators tagged with this CVE, per day0 indicators over 7 days
Block these indicators
  • Firewall list (EDL, text): https://api.ismalicious.com/edl/cve/CVE-2026-99239?format=txt
  • CSV export: https://api.ismalicious.com/edl/cve/CVE-2026-99239?format=csv
  • TAXII collection of exploited CVEs
  • The EDL and CSV take an API key on the Pro plan.

Versions per branch

Products declared by the CNA

As Linux, the CNA that assigned this CVE, declared them in the CVE record; versions as written. NVD lists no product for this CVE yet: this is the only product data so far.

  • Linuxother versions: not affected

    https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

    Affected
    • ≥ 8f90405a4a6f1f1880dc07996b47bf57c712bd8a, < 85cc289eb08afa975375f838187369e68b429ee0fixed in 85cc289eb08afa975375f838187369e68b429ee0git
    • ≥ 32d783cafb46ff3ca58e6f9fd62c9c5f35eaf26b, < 820579652b24ce277e0097cd65b42bd9b7b8bf07fixed in 820579652b24ce277e0097cd65b42bd9b7b8bf07git
    • ≥ 8922c7940bae9ce4b1736dddb6362370793835c2, < e618d928ec7f88cbeadfa3542adcac40f474e629fixed in e618d928ec7f88cbeadfa3542adcac40f474e629git
    • ≥ 91047a4396a8b1857a6f712a90cf33ec0012b189, < fabaff1c59ff2cc89cb7e5bd0186a5e15f0c73b2fixed in fabaff1c59ff2cc89cb7e5bd0186a5e15f0c73b2git
    • ≥ 0b0e2bf39cf99e458d991b9df253727e036a7d7d, < 52fe88e4ef87311eee32b45c65603e7c69e75e7dfixed in 52fe88e4ef87311eee32b45c65603e7c69e75e7dgit
    • ≥ d3b739db5dc6f688a60d56da872fabaf65246032, < 10c705dd706aa93164ba41f2566f15206d6c178efixed in 10c705dd706aa93164ba41f2566f15206d6c178egit
    • ≥ b66774b48dd98f07254951f74ea6f513efe7ff8b, < 73820561d8cbfd3364a29b8fa77f1707f26029dafixed in 73820561d8cbfd3364a29b8fa77f1707f26029dagit
    • ≥ b66774b48dd98f07254951f74ea6f513efe7ff8b, < d3afd7803f9bc2a8c4270199497b60158b2fc647fixed in d3afd7803f9bc2a8c4270199497b60158b2fc647git

    8 more version lines in the CVE record.

  • Linuxother versions: affected

    https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

    Affected
    • = 7.2no fix stated

    Not affected < 7.2 · ≥ 5.10.273, ≤ 5.10.* · ≥ 5.15.224, ≤ 5.15.* · ≥ 6.1.191, ≤ 6.1.* · ≥ 6.6.161, ≤ 6.6.* · ≥ 6.12.115, ≤ 6.12.* · ≥ 6.18.60, ≤ 6.18.*

    2 more version lines in the CVE record.

Source: the CNA record (CVE Program), © The MITRE Corporation,CVE Terms of UseCVE recordupdated 2026-11-02

Neither OSV.dev nor the vendor advisories we read list affected versions for CVE-2026-99239 yet.

Full record on NVD

Fix

No fix published by the sources we read yet. NVD record

Detection

Nuclei template
none so far
ProjectDiscovery
Exploit-DB
no entry
Exploit-DB
Proof-of-concept repositories
none listed
PoC-in-GitHub
Metasploit modules
none listed
Metasploit Framework

Sources

  • NVDCVE record2026-11-02
  • CNACVSS 3.17.82026-11-02

Technical details

CVSS v3 Vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Published
2026-11-02

Frequently asked questions

What is CVE-2026-99239?

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.

Is CVE-2026-99239 actively exploited?

Active exploitation of CVE-2026-99239 has not been confirmed.

What is the CVSS score for CVE-2026-99239?

CVE-2026-99239 has a CVSS v3 base score of 7.8 (HIGH severity), with vector string CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.

Running Linux kernel? Hear about its next vulnerability

Surveillance reads the versions in your stack — a domain, a lockfile or a list — checks each CVE against the ranges its sources publish, and alerts you when one you run is exploited or enters CISA KEV. A version it cannot read stays « version not verified ».

Get alerts for this productCISA KEV additions, October 2026Search CVEs

No credit card required · No monthly cap on website lookups · 250 API requests/month

Go further

Related vulnerabilities

Same product first, then the same vendor advisory and the same publication week.

Back to CVE Database

Sources for this record