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.
Executive briefing
The source record describes: 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. The practical risk depends on whether an affected product/version is present, reachable and configured in an exploitable way. Review the affected-product evidence and linked vendor advisories before assigning exposure status.
Evidence confidence: Low Evidence-derived, not an exploitability verdict
Severity & attack characteristics
CVSS vector:CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Technical explanation & impact
The technical mechanism is not expanded beyond the source description unless a referenced advisory supplies additional evidence. Read the linked vendor/CERT advisories for root-cause detail.
Potential impact must be interpreted from the published CVSS impact metrics and the affected component. A CVSS impact score is not proof that a particular asset is exploitable.
Affected products and versions
NVD has not supplied machine-readable vulnerable CPE product/version entries for this CVE. This is an information gap, not proof that no products are affected. Check the vendor advisory references below.
Remediation & validation
- Identify exposure by comparing the affected product and version ranges with your asset inventory, SBOM and externally exposed services.
- Review the linked vendor security advisory or patch notes. Upgrade to a vendor-confirmed fixed release; do not infer a fixed version from the CVE description.
- Until patched, consider restricting network access or disabling the affected feature where operationally safe. These are temporary controls, not a substitute for a vendor fix.
- Validate the remediation with a version check and vulnerability rescan, then retain change evidence.
No fixed version is displayed unless it is explicitly established by a vendor advisory. Follow the vendor's release notes for exact product and branch applicability.
Vendor advisories, patches & exploit references
- https://git.kernel.org/stable/c/10c705dd706aa93164ba41f2566f15206d6c178e REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- https://git.kernel.org/stable/c/52fe88e4ef87311eee32b45c65603e7c69e75e7d REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- https://git.kernel.org/stable/c/73820561d8cbfd3364a29b8fa77f1707f26029da REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- https://git.kernel.org/stable/c/820579652b24ce277e0097cd65b42bd9b7b8bf07 REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- https://git.kernel.org/stable/c/85cc289eb08afa975375f838187369e68b429ee0 REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- https://git.kernel.org/stable/c/86b55991d3cd690e73c5ef8d20b75ae4905b357a REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- https://git.kernel.org/stable/c/d3afd7803f9bc2a8c4270199497b60158b2fc647 REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- https://git.kernel.org/stable/c/e618d928ec7f88cbeadfa3542adcac40f474e629 REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- https://git.kernel.org/stable/c/fabaff1c59ff2cc89cb7e5bd0186a5e15f0c73b2 REFERENCE 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Information gaps & confidence notes
These gaps indicate missing source data. CVE Watch does not fill them with guessed product, exploit or patch details.
- NVD does not currently provide machine-readable vulnerable CPE product/version entries for this record.
- No vendor advisory or patch reference was identified in the supplied CVE references.
- No CWE classification is currently available.
Last enrichment: 2026-11-03T20:31:50+00:00 · Source last modified: 2026-11-03T20:18:30.280