Zephyr RTOS CVE-2026-11742

Exploitation requires local access with at least low privileges (PR:L per CVSS vector) and the ability to operate on a shared k_queue concurrently with another thread or CPU executing k_queue_get - making SMP builds or builds with preemption or ISR concurrency the primary risk surface. CONFIG_USERSPACE must be enabled for the userspace system-call attack path; without it, only kernel-internal callers can trigger the race. A narrow timing window (AC:H) must be won between the peek's pointer load and its dereference. Single-CPU builds without preemption cannot trigger this race at all, as the sequence cannot be interleaved. The vulnerability does not apply when peek and get operations on the same queue are inherently serialized by application design. No remote or network-accessible attack vector exists.

CVSS 3.6 (AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:L) accurately reflects a low-severity finding: exploitation is confined to local access, requires winning a narrow race window (AC:H), and yields only a stale one-pointer heap leak or system crash rather than privilege escalation or remote code execution. No EPSS score was provided in source data; the AC:H and local-only vector strongly imply very low exploitation probability in practice. The vulnerability is absent from the CISA KEV catalog and no public exploit code has been identified, corroborating the low-risk assessment. The most realistic real-world impact is a denial-of-service crash in embedded networking or Bluetooth stacks that dereference the dangling pointer as a live buffer. The wildcard CPE with no version bounds means the full scope of affected releases is unconfirmed. On single-CPU non-preemptive builds the race cannot materialize at all, further constraining the practical attack surface to a subset of Zephyr deployments.

On a Zephyr SMP or preemptive build with CONFIG_USERSPACE enabled, a local userspace process spawns two threads sharing a k_queue populated with alloc-enqueued items - one repeatedly calling k_queue_peek_head and the other calling k_queue_get. When the race is won, peek returns a dangling pointer to a freed alloc_node; downstream networking or Bluetooth subsystem code that treats this as a live net_buf then dereferences invalid memory, crashing the kernel or exposing the freed allocation's stale contents. No public exploit code has been identified at time of analysis.