Description
The Bluetooth Classic (BR/EDR) L2CAP receive handler bt_l2cap_br_recv() in subsys/bluetooth/host/classic/l2cap_br.c dispatched inbound data PDUs based only on the destination channel ID, without checking that the target channel had reached the BT_L2CAP_CONNECTED state. A dynamic channel is assigned its RX CID and added to the connection's channel list while still in BT_L2CAP_CONNECTING (and later BT_L2CAP_CONFIG) — before configuration completes and, for PSMs that require security, before the peer is authenticated (l2cap_br_conn_req()).

Because the channel is already findable by bt_l2cap_br_lookup_rx_cid() during this window, a remote peer within radio range can send a data PDU addressed to that CID and have it processed on a not-yet-established channel. The dispatch keys off channel fields (BR_CHAN(chan)->rx.mode, rx.mps) that are only initialized during configuration by l2cap_br_conf(); since channel objects are pooled and bt_l2cap_br_chan_del() does not reset rx.mode or the reassembly buffer _sdu, a reused channel can carry stale state into the CONNECTING window and route the frame into the retransmission/flow-control path (bt_l2cap_br_ret_fc_recv()) with stale parameters and a possibly stale _sdu pointer.

The impact is delivery of attacker data to upper-layer protocol handlers on a half-open (and possibly unauthenticated) channel, plus operation on stale or partially initialized channel state on reused channel objects — leading to channel/link teardown (denial of service) and, in the stale-_sdu case, a dangling-pointer condition. The fix adds an explicit BR_CHAN(chan)->state < BT_L2CAP_CONNECTED guard that drops any data received before the channel is fully connected.
Published: 2026-09-09
Score: 5.4 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service and potential memory safety issues
Action: Apply Patch
AI Analysis

Impact

The Zephyr Bluetooth Classic L2CAP receive handler processes data PDUs without verifying that a channel is fully connected. An attacker can send a data packet to a channel still in the CONNECTING or CONFIGURATION state, causing the packet to be delivered to upper‑layer protocol handlers on a half‑open channel, potentially leading to a denial of service or a dangling‑pointer condition when stale channel state is reused.

Affected Systems

The flaw affects Zephyr RTOS (Zephyr project) devices that use the Bluetooth Classic L2CAP receive path. The affected code is in subsys/bluetooth/host/classic/l2cap_br.c. Exact Zephyr versions are not specified in the advisory, so any build that includes this source file is potentially vulnerable until the patch is applied.

Risk and Exploitability

With a CVSS score of 5.4 the vulnerability is considered moderate. No EPSS score is available and it is not listed in KEV. The exploit requires a remote peer to be within radio range and to send a crafted L2CAP data PDU addressed to the target channel identifier. Once the packet is received it bypasses the CONNECTED state check, triggering channel processing on a not‑yet‑established or reused channel, which can cause channel teardown, denial of service or memory corruption. Because the window exists when the channel is in CONNECTING/CONFIGURATION, the likelihood of exploitation in the wild is low but still possible for systems exposed to Bluetooth traffic.

Generated by OpenCVE AI on September 10, 2026 at 00:05 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the Zephyr patch that introduces the BR_CHAN(state) guard in bt_l2cap_br_recv(), which fixes the CWE‑666 flaw by ensuring the channel is fully connected before processing data.
  • If your platform does not yet include the patch, manually apply the commit referenced in the advisory to enforce the CONNECTED state check and address the CWE‑666 weakness.
  • If Bluetooth Classic is not required, disable it through the device tree or configuration to eliminate the vulnerable L2CAP path associated with CWE‑666.

Generated by OpenCVE AI on September 10, 2026 at 00:05 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 10 Sep 2026 18:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Thu, 10 Sep 2026 11:15:00 +0000

Type Values Removed Values Added
First Time appeared Zephyrproject
Zephyrproject zephyr
Vendors & Products Zephyrproject
Zephyrproject zephyr

Wed, 09 Sep 2026 22:45:00 +0000

Type Values Removed Values Added
Description The Bluetooth Classic (BR/EDR) L2CAP receive handler bt_l2cap_br_recv() in subsys/bluetooth/host/classic/l2cap_br.c dispatched inbound data PDUs based only on the destination channel ID, without checking that the target channel had reached the BT_L2CAP_CONNECTED state. A dynamic channel is assigned its RX CID and added to the connection's channel list while still in BT_L2CAP_CONNECTING (and later BT_L2CAP_CONFIG) — before configuration completes and, for PSMs that require security, before the peer is authenticated (l2cap_br_conn_req()). Because the channel is already findable by bt_l2cap_br_lookup_rx_cid() during this window, a remote peer within radio range can send a data PDU addressed to that CID and have it processed on a not-yet-established channel. The dispatch keys off channel fields (BR_CHAN(chan)->rx.mode, rx.mps) that are only initialized during configuration by l2cap_br_conf(); since channel objects are pooled and bt_l2cap_br_chan_del() does not reset rx.mode or the reassembly buffer _sdu, a reused channel can carry stale state into the CONNECTING window and route the frame into the retransmission/flow-control path (bt_l2cap_br_ret_fc_recv()) with stale parameters and a possibly stale _sdu pointer. The impact is delivery of attacker data to upper-layer protocol handlers on a half-open (and possibly unauthenticated) channel, plus operation on stale or partially initialized channel state on reused channel objects — leading to channel/link teardown (denial of service) and, in the stale-_sdu case, a dangling-pointer condition. The fix adds an explicit BR_CHAN(chan)->state < BT_L2CAP_CONNECTED guard that drops any data received before the channel is fully connected.
Title Missing channel-state validation in Zephyr Bluetooth Classic L2CAP receive path
Weaknesses CWE-666
References
Metrics cvssV3_1

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

Subscriptions

Zephyrproject Zephyr
cve-icon MITRE

Status: PUBLISHED

Assigner: zephyr

Published:

Updated: 2026-09-10T17:50:55.003Z

Reserved: 2026-07-10T20:12:00.707Z

Link: CVE-2026-15460

cve-icon Vulnrichment

Updated: 2026-09-10T17:50:34.923Z

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-09-09T23:16:54.617

Modified: 2026-09-10T18:17:55.767

Link: CVE-2026-15460

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-10T11:00:09Z

Weaknesses
  • CWE-666

    Operation on Resource in Wrong Phase of Lifetime