Zephyr BLE Controller EUVD-2026-97109

Requires an established LE connection to a Zephyr Bluetooth LE Controller (peripheral or central role) with no pairing or encryption needed, and the attacker must be within Bluetooth radio range (Adjacent). The attacker must drive a PHY Update procedure to an accepted state with a future instant - sending LL_PHY_REQ, receiving LL_PHY_RSP, and sending a valid LL_PHY_UPDATE_IND with an instant a few connection events ahead so the RX node becomes retained - then, before that instant is reached, send any other LL Control PDU (e.g. LL_LENGTH_REQ); the mirror case is a locally initiated PHY Update followed by LL_REJECT_IND. Limiting factors: exploitation is confined to Bluetooth range and to builds with the vulnerable PHY Update/Connection Update/CIS-create paths; in the default configuration a single sequence crashes the device via assertion, but on releases v3.4.0 through v3.7.x the assertion is never reached so the attacker must repeat the sequence several times (each costing only a reconnect) to exhaust the small receive pool, which defaults to CONFIG_BT_CTLR_RX_BUFFERS=1.

The CVSS 3.1 vector (AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 6.5) is internally consistent with the description: exploitation is from Bluetooth radio range (Adjacent, not Network), low complexity and deterministic, requires no pairing or encryption (PR:N), and yields a pure availability impact (C:N/I:N/A:H). This is a genuine denial-of-service priority for exposed Zephyr BLE devices because it is unauthenticated, deterministic, and cheap to repeat, but it is bounded: no CISA KEV listing, no public exploit code identified, and no EPSS score was supplied, so there is no evidence of active or widespread exploitation. The impact is availability-only - the description explicitly rules out memory corruption or information disclosure, directly contradicting the input Tags 'Buffer Overflow' and 'Information Disclosure', which are mislabeled and should not inflate the perceived severity. Note a version-dependent behavior split the analyst must weigh: in the default configuration (CONFIG_BT_ASSERT / CONFIG_BT_CTLR_ASSERT_DEBUG = y) a single crafted PDU sequence triggers a controller assertion and faults the device (k_oops/k_panic), whereas on releases v3.4.0 through v3.7.x the assertion is never reached and each attempt silently leaks one RX node, requiring a few repetitions to exhaust the small receive pool (PDU_RX_CNT default 1).

An attacker within Bluetooth radio range of a Zephyr-based peripheral establishes an unauthenticated LE connection, negotiates a PHY Update with a future instant so the controller retains an RX node, then sends an unexpected LL Control PDU (e.g. LL_LENGTH_REQ) before the instant is reached, driving the invalid-PDU path that leaks the retained node. In default builds this trips a controller assertion and faults the device with one sequence; on v3.4.0-v3.7.x the attacker reconnects and repeats a handful of times to exhaust the receive pool and render Bluetooth inoperable until reboot. No public exploit code was identified, though the patch commit publicly details the exact triggering sequence.