EUVD-2026-75212Severity by source
AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
Adjacent-only Bluetooth vector; no authentication or privileges required; bounded integrity impact from injected data and availability from link teardown; no confidentiality exposure.
Primary rating from Vendor (zephyr).
CVSS VectorVendor: zephyr
Lifecycle Timeline
2DescriptionCVE.org
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.
AnalysisAI
Bluetooth Classic L2CAP channel state confusion in Zephyr RTOS (versions 1.6.0 through pre-4.4.2) enables an adjacent unauthenticated peer to inject data PDUs into half-open L2CAP channels before configuration or security handshaking completes, forcing processing on stale or uninitialized channel fields. In the worst case, reused channel objects expose dangling _sdu reassembly buffer pointers, creating a memory-safety condition that causes channel and link teardown (denial of service) alongside unintended delivery of attacker-controlled data to upper-layer protocol handlers. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Target device must run Zephyr 1.6.0 through pre-4.4.2 compiled with Bluetooth Classic support (CONFIG_BT_BREDR=y) and must be discoverable or connectable by the attacker. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | With CVSS 5.4 (AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L), the attack is bounded to Bluetooth radio range - typically 10 to 100 meters - which eliminates internet-scale mass exploitation but is operationally meaningful in dense shared environments such as hospitals, office buildings, and transit hubs where IoT devices running Zephyr may coexist with untrusted parties. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | Full exploit scenario with step-by-step reproduction available after sign-in. |
| Remediation | Upgrade to Zephyr 4.4.2 or later, which incorporates the fix from commit 2738ee921ba61ba2e644c95bceba302896dd8c19 adding an explicit BR_CHAN(chan)->state < BT_L2CAP_CONNECTED guard in bt_l2cap_br_recv() that drops any data PDU received before the channel reaches BT_L2CAP_CONNECTED. … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
Potential off-by-one buffer overflow vulnerability in the Zephyr fuse file system. Rated critical severity (CVSS 10.0),
Possible variant of CVE-2021-3434 in function le_ecred_reconf_req. Rated critical severity (CVSS 9.8), this vulnerabilit
Unchecked user input length in /subsys/net/l2/wifi/wifi_shell.c can cause buffer overflows. Rated critical severity (CVS
Potential buffer overflow vulnerability in the Zephyr CAN bus subsystem. Rated critical severity (CVSS 9.8), this vulner
Integer Underflow in 6LoWPAN IPHC Header Uncompression in Zephyr. Rated critical severity (CVSS 9.8), this vulnerability
Buffer overflow in Zephyr USB DFU DNLOAD. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable
DOS: Incorrect 802154 Frame Validation for Omitted Source / Dest Addresses. Rated critical severity (CVSS 9.8), this vul
zephyr-rtos version 1.12.0 contains a NULL base pointer reference vulnerability in sys_ring_buf_put(), sys_ring_buf_get(
Potential buffer overflow vulnerabilities n the Zephyr Bluetooth subsystem. Rated critical severity (CVSS 9.6), this vul
Buffer overflow in Zephyr RTOS dns_unpack_name() function causing OOB writes. PoC available.
The documentation specifies that the BT_GATT_PERM_READ_LESC and BT_GATT_PERM_WRITE_LESC defines for a Bluetooth characte
Potential buffer overflows in the Bluetooth subsystem due to asserts being disabled in /subsys/bluetooth/host/hci_core.c
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today