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.
Published: 2026-11-02
Score: 7.8 High
EPSS: n/a
KEV: No
Impact: Denial of Service
Action: Immediate Patch
AI Analysis

Impact

The vulnerability is a race condition in the Linux kernel Bluetooth L2CAP stack. It arises when a channel is in the process of being connected or bound, allowing a second __l2cap_chan_add call before the first operation completes. This violates the invariant that a channel may be linked to a connection at most once, potentially causing the kernel to crash or exhibit undefined behaviour. The lack of proper locking and state checks means the bug could be triggered by local processes that create and bind Bluetooth sockets in a time‑sensitive manner. The impact is primarily a denial‑of‑service, as the kernel crash would bring down the entire system, but it does not directly provide code execution or elevated privileges.

Affected Systems

All Linux kernel releases that contain the vulnerable Bluetooth L2CAP implementation are affected. No specific kernel versions are listed, so any system running a recent kernel with Bluetooth support should be considered potentially vulnerable until a fix is applied via the Linux kernel update channel.

Risk and Exploitability

The CVSS score of 7.8 indicates a Medium‑High severity. The EPSS score is not available, and the vulnerability is not listed in the CISA KEV catalog. The likely attack vector is local, achieved by a malicious or compromised user space application that interacts with the Bluetooth stack. The race condition requires careful timing, so exploitation is non‑trivial but feasible on systems where high concurrency of Bluetooth socket operations is possible. Until the patch is installed, the kernel may crash, leading to service disruption.

Generated by OpenCVE AI on November 2, 2026 at 17:51 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update to a Linux kernel release that contains the patch correcting the L2CAP race condition (consult vendor advisories or the Linux kernel git logs referenced above).
  • If an immediate kernel update is not feasible, disable or restrict the Bluetooth service on the host to prevent the vulnerable code path from being exercised.
  • Monitor kernel logs for WARN_ON_ONCE messages related to L2CAP; if such warnings appear, treat them as indicators that the vulnerability is active and raise the urgency to apply a fix.

Generated by OpenCVE AI on November 2, 2026 at 17:51 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Mon, 02 Nov 2026 19:15:00 +0000

Type Values Removed Values Added
First Time appeared Linux linux
Vendors & Products Linux linux

Mon, 02 Nov 2026 18:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362

Mon, 02 Nov 2026 16:15:00 +0000

Type Values Removed Values Added
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.
Title Bluetooth: L2CAP: refuse __l2cap_chan_add if chan already has conn
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References
Metrics cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}


Subscriptions

Linux Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-11-02T16:06:43.262Z

Reserved: 2026-09-25T10:25:14.403Z

Link: CVE-2026-99239

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-11-02T16:17:49.540

Modified: 2026-11-02T16:17:49.540

Link: CVE-2026-99239

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-11-02T19:00:06Z

Weaknesses
  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')