Zephyr RTOS CVE-2026-12234

CONFIG_USERSPACE must be enabled in the Zephyr build configuration - this is the mandatory gating condition, as the vulnerability exists entirely within the z_vrfy_* syscall verifier layer that is only compiled in when this option is set. The zsock_sendmsg and zsock_recvmsg syscalls must be available and permitted to the calling thread. The attacker must have the ability to execute unprivileged code on the target device and to spawn or coordinate with a cooperating second thread within the same process and memory domain, as the exploit depends on a thread race to modify msg_iovlen between two kernel reads - a single-threaded attacker cannot trigger the vulnerability. Exploitation is further constrained by AC:H: the race window is narrow and hardware-platform-dependent, requiring precise thread scheduling behavior that may vary significantly across Zephyr target architectures (ARM Cortex-M, RISC-V, x86 sim, etc.) and scheduler configurations. The attacker must already hold a running thread on the device (PR:L per CVSS); remote unauthenticated network exploitation is not possible - this is strictly a local privilege-escalation or denial-of-service primitive that cannot be triggered by external network input alone.

The CVSS 3.1 score of 7.8 (AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H) accurately captures the tension between difficult exploitation and catastrophic impact: AC:H reflects the genuine timing constraint of winning the race on real hardware, while S:C with full C/I/A acknowledges that a successful exploit crosses the user-to-kernel privilege boundary with unconstrained kernel heap control. EPSS data was not supplied in the available intelligence, limiting probabilistic exploitation forecasting; the CVE is not listed in the CISA KEV catalog and no public proof-of-concept has been identified, so confirmed active exploitation cannot be asserted. SSVC dimensions indicate: exploitation status is 'none' (no public weaponization), the attack is not automatable (requires local code execution, thread co-scheduling, and hardware-dependent race timing), and technical impact is 'total' if the race is won. Despite the high attack complexity, the severity for any Zephyr deployment with CONFIG_USERSPACE enabled warrants urgent attention - kernel heap corruption primitives of this class (heap OOB write with attacker-controlled content) have historically been converted into reliable exploits by skilled researchers given sufficient platform access and scheduling profiling time, even when initial win rates are low. The absence of EPSS and KEV data means risk must be assessed primarily from the CVSS vector and the nature of the primitive itself; the high-complexity bar meaningfully reduces near-term mass exploitation risk but does not eliminate targeted exploitation risk against higher-value embedded targets.

An attacker with the ability to execute unprivileged code on a Zephyr device built with CONFIG_USERSPACE enabled spawns two cooperating threads in the same address space. The first thread calls zsock_sendmsg() with a crafted net_msghdr where msg_iovlen is initialized to a small, allocation-safe value; the second thread spins racing to inflate msg_iovlen in the narrow window between the kernel's buffer-sizing read and its copy-loop bound check. If the race is won, the kernel's iovec population loop iterates past the end of its heap-allocated shadow buffer, writing attacker-controlled iov_base and iov_len values into adjacent kernel heap objects, which can then be leveraged for kernel privilege escalation or to induce a kernel panic.