{"id":"CVE-2026-15460","title":"Missing channel-state validation in Zephyr Bluetooth Classic L2CAP receive path","summary":"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 reach…","severity":"medium","cvss":5.4,"cvssVector":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L","cvssSource":"cna","cwe":["CWE-666"],"vendor":"zephyrproject","product":"zephyr","affected":["zephyr >= 1.6.0 < 4.4.2"],"ssvc":{"exploitation":"none","automatable":"no","technicalImpact":"partial","timestamp":"2026-09-10T17:50:21.102172Z"},"published":"2026-09-09","updated":"2026-09-10","sourceUpdated":"2026-09-10T17:50:55.003Z","source":"CVEORG","sourceUrl":"https://www.cve.org/CVERecord?id=CVE-2026-15460","references":[{"url":"https://github.com/zephyrproject-rtos/zephyr/commit/2738ee921ba61ba2e644c95bceba302896dd8c19","label":"Fix commit"},{"url":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-hx89-rm6c-hjrh","label":"GHSA-hx89-rm6c-hjrh"}],"tags":["cve.org"],"epss":0.00159,"epssPercentile":0.05419,"ingestedAt":"2026-09-11T11:32:42.883Z","slug":"CVE-2026-15460","body":"## Overview\n\nThe 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()).\n\nBecause 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.\n\nThe 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.\n\n## Affected\n\n- `zephyr >= 1.6.0 < 4.4.2`\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.","depth":"sunlit","depthScore":30,"depthScoreParts":{"impact":29.7,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}