The Bluetooth Classic (BR/EDR) L2CAP receive handler in Zephyr (bt_l2cap_br_recv) dispatches inbound data PDUs based only on the destination channel ID, without verifying that the target channel has reached the BT_L2CAP_CONNECTED state. Dynamic channels are assigned RX CIDs and added to the connection's channel list while still in the BT_L2CAP_CONNECTING or BT_L2CAP_CONFIG states, before configuration and authentication complete. Because the channel is findable during this window, a remote peer can send data PDUs to a not-yet-established channel. The dispatch uses channel fields initialized only during configuration, so reused channel objects can carry stale state, leading to processing with stale parameters and a dangling-pointer condition. The impact includes delivery of attacker data to upper-layer protocol handlers on half-open or unauthenticated channels, denial of service via channel/link teardown, and potential memory corruption. The fix involves adding a guard to drop data received before the channel is fully connected.

An attacker within radio range can send data to a Bluetooth L2CAP channel that is not fully connected or authenticated, causing the system to process attacker data on half-open channels. This can lead to denial of service by tearing down channels or links, and in some cases, a dangling-pointer condition that may cause memory corruption or instability. There is no indication of confidentiality impact, but integrity and availability impacts are present.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The described fix adds a state check to drop data received before the channel is fully connected. Until a patch is available, consider limiting Bluetooth Classic exposure to untrusted peers or disabling affected functionality if feasible.