Executive brief
Zephyr's Bluetooth Classic L2CAP receive handler processes inbound data on partially-established channels without proper state validation. An attacker within radio range can send malicious data to a channel during its connection setup phase, before authentication and security checks complete. This can cause the channel to hang up or crash the Bluetooth stack, or in some cases lead to memory corruption through stale channel state.
Technical details
The vulnerability exists in the bt_l2cap_br_recv() handler in subsys/bluetooth/host/classic/l2cap_br.c, which dispatches L2CAP data PDUs based only on the destination channel ID without verifying the channel has reached BT_L2CAP_CONNECTED state. Dynamic channels are added to the connection's channel list and assigned their RX CID while still in BT_L2CAP_CONNECTING or BT_L2CAP_CONFIG states, before configuration completes and authentication checks pass. Because the channel is findable by bt_l2cap_br_lookup_rx_cid() during this window, a remote peer can send a data PDU to that CID and have it processed. The dispatch uses uninitialized or stale channel state (rx.mode, rx.mps, _sdu pointer) from pooled channel objects, routing frames through the retransmission/flow-control path with incorrect parameters. This results in channel/link teardown (denial of service) or dangling-pointer dereferences. The fix adds an explicit state guard to drop data received before BT_L2CAP_CONNECTED.
Affected products
- Zephyr Zephyr OS versions with vulnerable Bluetooth Classic stack
Timeline
- 2026-09-09: disclosed
- 2026-09-09: advisory: CVE-2026-15460