Zephyr RTOS CVE-2026-16513

Exploitation requires a Zephyr firmware image built with BOTH CONFIG_USERSPACE and CONFIG_RTIO enabled - without CONFIG_USERSPACE the verifier is not compiled and the caller is already privileged, so unaffected builds are entirely immune. The attacker must already be executing as a user-mode thread that has been granted a struct rtio kernel object (this is the ordinary way apps use the RTIO API, e.g. via sensor_read_async_mempool() or the async ADC helpers), so local code execution and a granted RTIO handle are prerequisites (PR:L, AV:L). No user interaction is needed and the malicious store fires in supervisor mode before any SQE-content validation, so it succeeds regardless of whether the submission entry is later rejected. The limiting factors are: local access only (not network-reachable), the specific two-Kconfig build combination, and possession of an rtio object grant.

This is a genuine, high-quality memory-corruption flaw whose real-world risk is moderated by its exploitation surface rather than its severity ceiling. The vendor CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, 7.8) is well-supported by the technical detail: a missing K_SYSCALL_MEMORY_WRITE check on the handle out-parameter of z_vrfy_rtio_sqe_copy_in_get_handles() yields a write-what-where primitive (attacker-chosen address, value = pointer into caller-controlled RTIO ring), which is enough to corrupt kernel function pointers, thread structures, or memory-domain partition tables and escalate from user mode to supervisor mode. The attack is LOCAL (AV:L) and requires an already-running user-mode thread that has been granted a struct rtio kernel object (PR:L), so this is not a remotely reachable network bug - it is a local-privilege-escalation / sandbox-escape primitive that defeats the CONFIG_USERSPACE isolation boundary. No EPSS score, no CISA KEV entry, and no packaged public exploit are present in the input, so there is no evidence of active or automated exploitation; however, the reporter reproduced a real write on qemu_x86 (a K_USER thread flipped a supervisor global from NULL to a live kernel SQE pointer), meaning exploitability is demonstrated even if weaponized code is not public. Net: a real priority for anyone shipping Zephyr with both CONFIG_USERSPACE and CONFIG_RTIO, but its blast radius is confined to that specific build configuration, so it is not a mass-exploitation, high-EPSS-style threat.

On a Zephyr device built with CONFIG_USERSPACE and CONFIG_RTIO, a low-privileged user-mode application thread that legitimately holds an rtio kernel object (e.g. one using sensor_read_async_mempool() or the async ADC helpers) calls rtio_sqe_copy_in_get_handles() with an arbitrary kernel address in the handle argument. Because the verifier stores *handle = sqe before any K_SYSCALL_MEMORY_WRITE check, the kernel writes a pointer to attacker-controlled ring data at that address, giving a write-what-where primitive the reporter has already reproduced on qemu_x86. The attacker uses this to overwrite a kernel function pointer or memory-domain partition table and escalate from user mode to supervisor mode.