CVE-2026-15460: Bluetooth L2CAP DOS Vulnerability

CVE-2026-15460 Overview

CVE-2026-15460 is a state validation flaw in the Zephyr RTOS Bluetooth Classic (BR/EDR) stack. The bt_l2cap_br_recv() handler in subsys/bluetooth/host/classic/l2cap_br.c dispatches inbound L2CAP data PDUs based solely on the destination channel ID. It does not verify that the target channel has reached the BT_L2CAP_CONNECTED state. A remote attacker within Bluetooth radio range can send data PDUs to a half-open channel and reach upper-layer protocol handlers before authentication or configuration completes. The flaw is tracked under [CWE-666: Operation on Resource in Wrong Phase of Lifetime].

Critical Impact
Attackers within radio range can deliver data to unauthenticated L2CAP channels, trigger link teardown, and exercise a dangling-pointer condition through reused channel objects carrying stale reassembly state.

Affected Products

Zephyr RTOS Bluetooth Classic host stack (subsys/bluetooth/host/classic/l2cap_br.c)
Devices exposing PSMs that require security over BR/EDR
Zephyr builds prior to the commit adding the connected-state guard

Discovery Timeline

2026-09-09 - CVE-2026-15460 published to NVD
2026-09-09 - Last updated in NVD database

Technical Details for CVE-2026-15460

Vulnerability Analysis

The defect lives in the L2CAP BR/EDR receive path. A dynamic channel is assigned its RX channel identifier (CID) and inserted into the connection's channel list while still in BT_L2CAP_CONNECTING and later BT_L2CAP_CONFIG. This happens before configuration finishes and, for PSMs requiring security, before the peer authenticates in l2cap_br_conn_req().

Because bt_l2cap_br_lookup_rx_cid() can already find the channel during this window, a peer within radio range can address a data PDU to that CID. bt_l2cap_br_recv() then processes the frame on a not-yet-established channel. Delivery to upper-layer protocol handlers on a half-open, potentially unauthenticated channel breaks the integrity model of L2CAP setup.

Root Cause

The root cause is missing lifecycle validation. bt_l2cap_br_recv() keys off channel fields such as BR_CHAN(chan)->rx.mode and rx.mps that l2cap_br_conf() only initializes during configuration. Channel objects are pooled, and bt_l2cap_br_chan_del() does not reset rx.mode or the reassembly buffer _sdu. A reused channel can therefore carry stale state into the CONNECTING window and route frames into bt_l2cap_br_ret_fc_recv() with stale parameters and a possibly stale _sdu pointer.

Attack Vector

Exploitation requires adjacent-network access over Bluetooth Classic. The attacker sends a crafted L2CAP data PDU targeting a CID that has been allocated but not yet promoted to BT_L2CAP_CONNECTED. The result is denial of service through channel or link teardown, plus a dangling-pointer condition when the stale _sdu pointer is dereferenced during reassembly.

// Zephyr patch: subsys/bluetooth/host/classic/l2cap_br.c
// Adds state validation in the L2CAP BR receive path

 	if (buf->len < sizeof(*hdr)) {
 		LOG_ERR("Too small L2CAP PDU received");
-		net_buf_unref(buf);
-		return;
+		goto done;
 	}
 
 	hdr = net_buf_pull_mem(buf, sizeof(*hdr));
// Source: [Zephyr commit 2738ee9](https://github.com/zephyrproject-rtos/zephyr/commit/2738ee921ba61ba2e644c95bceba302896dd8c19)

The upstream fix adds an explicit BR_CHAN(chan)->state < BT_L2CAP_CONNECTED guard that drops any data received before the channel is fully connected, routing early frames through a common cleanup label.

Detection Methods for CVE-2026-15460

Indicators of Compromise

Unexpected L2CAP link teardowns on BR/EDR interfaces shortly after connection requests from unpaired peers.
Log entries from bt_l2cap_br_recv() referencing data PDUs on channels still in CONNECTING or CONFIG state.
Crashes or faults in bt_l2cap_br_ret_fc_recv() correlating with reassembly operations on recently reused channel objects.

Detection Strategies

Enable verbose Bluetooth host logging and monitor for PDUs delivered to CIDs whose channel state is below BT_L2CAP_CONNECTED.
Capture over-the-air BR/EDR traffic during pairing and configuration to identify peers sending data frames before configuration completes.
Fuzz the L2CAP BR/EDR receive path with PDUs addressed to CIDs during the CONNECTING and CONFIG windows.

Monitoring Recommendations

Track firmware versions of deployed Zephyr-based devices and flag builds that predate the state-validation commit.
Alert on repeated abnormal L2CAP disconnections originating from the same Bluetooth address.
Correlate device reboots or watchdog resets with concurrent Bluetooth activity from unknown peers.

How to Mitigate CVE-2026-15460

Immediate Actions Required

Rebuild affected Zephyr firmware images against a tree that includes commit 2738ee921ba61ba2e644c95bceba302896dd8c19 and deploy to fielded devices.
Inventory devices running Zephyr with Bluetooth Classic enabled and prioritize those exposing security-required PSMs.
Disable Bluetooth Classic on devices where BR/EDR is not a required feature until patched firmware is available.

Patch Information

The fix is available in the Zephyr Project upstream repository. Review the Zephyr commit 2738ee9 and the GitHub Security Advisory GHSA-hx89-rm6c-hjrh for the full patch series and backport guidance.

Workarounds

Restrict device discoverability and connectability on BR/EDR when patched firmware cannot be deployed immediately.
Require out-of-band pairing procedures and reject inbound connections from unknown Bluetooth addresses at the application layer.
Reduce Bluetooth radio range or operate affected devices in physically controlled environments during the exposure window.

bash

# Verify the fix is present in your Zephyr source tree
git -C zephyr log --oneline 2738ee921ba61ba2e644c95bceba302896dd8c19 -1
git -C zephyr grep -n "state < BT_L2CAP_CONNECTED" subsys/bluetooth/host/classic/l2cap_br.c