CVE Feed
7.8 High

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: refuse l2capchanadd if chan already has conn…

CVE-2026-99239

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: refuse l2capchanadd if chan already has conn l2capchan may be linked to l2capconn at most once. This is assumed in several places, eg l2capchandel cleanup. There is a TOCTOU race where the invariant is violated: [Task 1] [Task 2] l2capchanconnect l2capsockbind l2capchanlock locksock l2capstatechange if (sk->skstate != BTOPEN) chan->state = BTCONNECT l2capsockstatechangecb chan->state = BTBOUND sk->skstate = BTBOUND locksock skstate = BTCONNECT l2capsockconnect() does not check sk->skstate, so since chan->state is now BTBOUND, subsequent connect() ends up with second l2capchanadd. Explicitly document and check the invariant in l2capchanadd with WARNONONCE. The only callsite where it could be hit is l2capchanconnect, 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 l2caplockchan in l2capsockbind() to guard chan->state write.

Assessment

CVSS
7.8 (v3.1)
Severity
High
Known exploited
Not listed in CISA KEV
Exploit availability
Nothing found in Exploit-DB, Metasploit, Nuclei or public PoC repositories
Published
2 November 2026
Last updated
2 November 2026
Affected
Linux · Linux
Assigner
Linux

CVSS vectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

At the source

References

Community proofs of concept

No community proof of concept yet. If you have one for a published vulnerability and the right to share it, add it below — it will appear here once reviewed.

Submit a proof of concept
Before you submit *

Query this programmatically

Agents can read this through the MCP endpoint, or over HTTP:

curl https://cve.zerocrew.in/api/cve/CVE-2026-99239