CVE-2026-15460 in Zephyr
Summary
by MITRE • 09/10/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/10/2026
The vulnerability resides within the Bluetooth Classic Link Layer Control Protocol (L2CAP) implementation in the Linux kernel, specifically affecting the receive handler function bt_l2cap_br_recv located in subsys/bluetooth/host/classic/l2cap_br.c. This flaw stems from a critical logic error where inbound data protocol data units are dispatched based solely on the destination channel identifier without verifying that the target channel has reached the BT_L2CAP_CONNECTED state. In standard Bluetooth operation, dynamic channels undergo a multi-stage establishment process involving connection requests and configuration phases before they become fully operational. However, during this interim period, when a channel is in either the CONNECTING or CONFIG states, it is already assigned a receive channel identifier and added to the connection's channel list. This premature availability allows remote peers within radio range to target these partially initialized channels with data packets that are processed by the stack before security measures such as peer authentication have been completed for protocols requiring secure connections.
The technical severity of this issue is amplified by how L2CAP manages memory and state for channel objects. Channel objects are allocated from a pool, meaning they can be reused across different connection contexts over time. When a previous use of a channel object ends, the deletion function bt_l2cap_br_chan_del fails to reset critical fields such as rx.mode or the reassembly buffer pointer _sdu. Consequently, when a new channel is created using this recycled memory block and enters the CONNECTING state, it carries stale configuration data from its prior incarnation. Because the dispatch logic does not validate the current operational state of the channel against these potentially corrupted parameters, incoming frames are routed into the retransmission and flow control path bt_l2cap_br_ret_fc_recv with incorrect or outdated settings. This creates a scenario where the protocol stack operates on inconsistent internal states that do not reflect the actual handshake progress between the local device and its peer.
The operational impact of this vulnerability is twofold, encompassing both denial of service and potential memory corruption risks. First, the delivery of attacker-controlled data to upper-layer protocol handlers over a half-open or unauthenticated channel can lead to unexpected behavior in higher-level services that assume secure establishment before processing payload content. Second, the operation on stale state variables introduces significant stability issues. Specifically, if the reused channel object retains a dangling pointer from its previous lifecycle phase, particularly within the _sdu reassembly buffer field, processing incoming data can trigger undefined memory access patterns. This condition directly leads to system instability, resulting in link teardowns and denial of service for Bluetooth services on the affected device. In more severe scenarios involving heap corruption due to invalid pointer dereferences during frame assembly, this could potentially be leveraged for arbitrary code execution, although the primary documented impact remains stability degradation through channel termination.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation and CWE-367 Time-of-check Time-of-use (TOCTOU) race condition principles, as the system checks the channel identifier but fails to validate its operational readiness state before processing data. It also relates to CWE-416 Use After Free in terms of handling stale pointers from recycled memory objects within the L2CAP layer. In the context of the MITRE ATT&CK framework for IoT and embedded systems, this flaw facilitates unauthorized access through protocol manipulation and can be categorized under techniques that exploit implementation flaws in communication protocols to disrupt service availability or gain footholds before authentication is enforced. The vulnerability highlights a common pitfall in network stack implementations where performance optimizations like object pooling are not adequately paired with strict state validation during initialization phases.
To mitigate this risk, the primary remediation involves enforcing explicit state checks within the L2CAP receive path. As implemented in the fix, an additional guard condition checking that BR_CHAN(chan)->state is less than BT_L2CAP_CONNECTED must be added to drop any data packets received before the channel has fully completed its establishment sequence. This ensures that no payload processing occurs until both configuration parameters are correctly initialized and security requirements such as authentication have been satisfied for applicable protocols. Beyond this specific code patch, system administrators should ensure their Bluetooth stack firmware is updated to include these state validation improvements. For developers maintaining custom Bluetooth stacks or embedded systems utilizing similar pooling mechanisms, it is imperative to implement rigorous zeroing of memory structures upon allocation and enforce strict state machine transitions that prevent data processing until the channel reaches a fully connected status. This approach eliminates the window of opportunity for attackers to exploit uninitialized states or stale pointers during the critical handshake phase.