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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-09-09T23:16:54.617Z",
  "pubdate": "2026-09-09T23:16:54.617Z",
  "executiveSummary": "This vulnerability involves improper state validation in the Bluetooth Classic (BR/EDR) L2CAP receive handler within the Zephyr Project Bluetooth stack. The issue resides in the bt_l2cap_br_recv() function located in subsys/bluetooth/host/classic/l2cap_br.c.\nThe vulnerability allows remote attackers within radio range to inject data PDUs into L2CAP channels that are in the 'CONNECTING' or 'CONFIG' states, before the connection is fully established or authentication has occurred. By bypassing the BT_L2CAP_CONNECTED state check, an attacker can trigger the processing of malformed or stale data.\nThe impact includes potential Denial of Service (DoS) via link teardown and, more critically, memory safety issues stemming from the use of stale or uninitialized channel state. Specifically, the processing of packets against stale reassembly buffers (the _sdu pointer) can result in dangling pointer conditions, potentially leading to memory corruption or arbitrary code execution. This vulnerability affects systems using the vulnerable L2CAP stack implementation and requires proximity to the target device, but does not require prior pairing or authentication.",
  "technicalDetails": "The root cause is a failure in the bt_l2cap_br_recv() function to enforce channel state synchronization before dispatching inbound data PDUs. In the affected implementation, a dynamic L2CAP channel is assigned a Receive Channel ID (RX CID) and added to the connection's active list while the state is still BT_L2CAP_CONNECTING or BT_L2CAP_CONFIG.\nBecause the function bt_l2cap_br_lookup_rx_cid() can successfully locate these channels while they are in a pre-connected state, the receive handler proceeds to process incoming data PDUs using fields that have not yet been initialized by the l2cap_br_conf() configuration process. Specifically, fields such as rx.mode and rx.mps may contain stale data from previously pooled channel objects.\nThe attack flow follows these steps: 1. An attacker identifies a target device in radio range initiating an L2CAP connection. 2. The attacker transmits a data PDU to the specific RX CID currently in the 'CONNECTING' phase. 3. The bt_l2cap_br_recv() function matches the CID and routes the frame to the retransmission/flow-control path (bt_l2cap_br_ret_fc_recv()) despite the channel not being fully established. 4. Because bt_l2cap_br_chan_del() does not explicitly clear the _sdu reassembly buffer or reset the rx.mode, the stack operates on stale parameters.\nThis exploitation path leads to two primary outcomes: First, the delivery of attacker-controlled data to upper-layer protocol handlers on an unauthenticated channel, bypassing security assumptions. Second, the use of stale internal structures, specifically the _sdu pointer, creates a dangling pointer condition. When the stack attempts to reassemble or process these frames, it references invalid or reused memory addresses. This behavior typically results in a system crash (Denial of Service) but could theoretically be weaponized to cause memory corruption or unauthorized state transitions depending on the context of the stale pointer and the surrounding heap layout. The vulnerability exists within the kernel-level Bluetooth stack implementation and can be triggered externally without authentication or pairing."
}