Zephyr RTOS EUVD-2026-97106

Requires a build with CONFIG_BT_L2CAP_DYNAMIC_CHANNEL enabled and a channel using a dynamic PSM in the 0x0080-0x00FF range; SIG-assigned PSMs such as EATT (0x0027) and OTS (0x0025) use the inline receive path and are NOT affected, nor are configurations without dynamic-channel support. The attacker must have an established CoC channel and send a data K-frame immediately followed by an L2CAP Disconnect Request to queue rx_work before teardown. Impact is further gated by the default CONFIG_BT_RECV_WORKQ_BT setting (RX processing on the dedicated Bluetooth workqueue while rx_work runs on the system workqueue) and, critically, by the application freeing or re-accepting the channel memory in its released() callback. Limiting factors: adjacent (in-radio-range) access only, a cooperative-scheduling race that must be won, and application-dependent memory handling - these reduce realistic exploitability below the raw 7.5 score.

Signals are mixed and point to a real-but-conditional risk rather than an urgent mass-exploitation threat. The CVSS 3.1 vector (AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, base 7.5) describes an adjacent (Bluetooth radio range), unauthenticated attack with HIGH attack complexity and full C/I/A impact - the HIGH complexity is well-justified because exploitation depends on winning a race between the system workqueue and the higher-priority Bluetooth RX workqueue AND on application-specific behavior (freeing or re-accepting the channel from the released() callback). There is no CISA KEV listing and no EPSS score provided, and no public exploit code is referenced, so there is no evidence of active or opportunistic exploitation. The adjacency requirement (AV:A, not AV:N) and the race-plus-application-dependency conditions substantially limit real-world exploitability despite the HIGH-severity C/I/A claim, so this reads as a credible defect to patch on affected builds rather than a drop-everything emergency. A notable nuance: whether the flaw yields code execution/disclosure or merely a workqueue-corruption denial of service depends heavily on how the downstream application manages channel memory - the vulnerability is in the Zephyr host, but impact is co-determined by application code.

A remote, unauthenticated peer within Bluetooth range establishes an L2CAP connection-oriented channel on a dynamic PSM (0x0080-0x00FF), then sends a data K-frame immediately followed by an L2CAP Disconnect Request. The K-frame queues rx_work on the system workqueue that cannot run before teardown completes, so after the released() callback the application frees or re-accepts the channel while the workqueue still holds a dangling reference, leading to a use-after-free dereference of a list node and handler pointer, workqueue list corruption, or a teardown race. No public exploit code is identified at time of analysis; successful exploitation also requires winning the cooperative-scheduling race and application memory handling that frees/reuses the channel.