Zephyr RTOS CVE-2026-9771

Exploitation requires all of the following: (1) CONFIG_USERSPACE must be enabled at build time - this is the decisive condition; without it, z_vrfy_flash_copy() is not compiled and the attack surface does not exist; (2) the attacker must have code execution as a low-privileged user-mode thread on the target device (PR:L per CVSS vector - a valid Zephyr userspace thread context); (3) the flash_copy() syscall must be accessible to the calling thread (not restricted by Zephyr's thread permission system). Exploitation is NOT gated by network access (AV:L), race conditions (AC:L), or user interaction (UI:N). The primary real-world limiting factor beyond CONFIG_USERSPACE is the requirement for existing local code execution - this is not remotely triggerable. Deployments that do not use CONFIG_USERSPACE or that use Zephyr's permission system to deny flash_copy() access to untrusted threads have meaningfully reduced exposure.

The CVSS 3.1 score of 8.8 with vector AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H is internally consistent with the description: the attack is local, requires only a low-privileged user-mode thread (PR:L), involves no race condition or complexity (AC:L), and achieves a full scope change - breaking out of the Zephyr userspace sandbox into kernel supervisor mode - with full confidentiality, integrity, and availability impact. The S:C (scope changed) metric is the most consequential signal here: this is not a contained userspace crash but a complete kernel compromise. No EPSS data was provided in the input, so exploitation probability cannot be quantified. No KEV listing exists, meaning CISA has not confirmed active exploitation. No public POC has been identified at time of analysis, though the published commit diff provides a sufficiently detailed roadmap that the exploit primitive (forge a struct device, invoke the syscall) is straightforward for a capable attacker. The principal real-world risk is an already-present low-privileged process on a Zephyr-based embedded or IoT device escalating to full kernel control - a particularly acute concern in safety-critical or industrial deployments. The limiting factor is CONFIG_USERSPACE: builds without this feature are entirely unaffected, which meaningfully reduces the exposed population.

An attacker with code execution as a low-privileged user-mode thread on a Zephyr 4.0.0-4.4.1 device (CONFIG_USERSPACE enabled) allocates a forged struct device in their own address space, populating its api field with a pointer to an attacker-controlled function table. The thread calls flash_copy() passing the forged pointer as src_dev or dst_dev; z_vrfy_flash_copy() accepts the pointer without kernel-object validation, and z_impl_flash_copy() dereferences the forged API table and calls the attacker's function in supervisor mode, achieving full kernel privilege escalation. No public proof-of-concept has been identified, but the exploit primitive is straightforward given the published commit diff detailing exactly which validation was absent.