The Bluetooth Classic (BR/EDR) L2CAP receive handler btl2capbrrecv() in subsys/bluetooth/host/classic/l2capbr.c dispatched inbound data PDUs based only on the destination channel ID, without checking that the target channel had reached the BTL2CAPCONNECTED state. A dynamic channel is assigned its RX CID and added to the connection's channel list while still in BTL2CAPCONNECTING (and later BTL2CAPCONFIG) — before configuration completes and, for PSMs that require security, before the peer is authenticated (l2capbrconnreq()).

Because the channel is already findable by btl2capbrlookuprxcid() 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 (BRCHAN(chan)->rx.mode, rx.mps) that are only initialized during configuration by l2capbrconf(); since channel objects are pooled and btl2capbrchandel() 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 (btl2capbrretfcrecv()) 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 BRCHAN(chan)->state < BTL2CAPCONNECTED guard that drops any data received before the channel is fully connected.