CVE-2026-15460

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.