Zephyr RTOS CVE-2026-19595

Exploitation requires the device to be built with BOTH CONFIG_USERSPACE and CONFIG_RTIO_SYS_MEM_BLOCKS (the configuration behind RTIO_DEFINE_WITH_MEMPOOL); without CONFIG_RTIO_SYS_MEM_BLOCKS the implementation returns -ENOTSUP and writes nothing, so the flaw is unreachable. The attacker must already be an unprivileged user-mode thread that has been granted access to the RTIO context via rtio_access_grant(). The thread must supply a completion-queue entry with RTIO_CQE_FLAG_MEMPOOL_BUFFER set in flags[7:0] (block index in flags[19:8], count in flags[31:20]) and buff/buff_len pointers to memory it can read but not write. Limiting factors: no remote vector (local user-mode thread only), the RTIO access grant must have been issued beforehand, and the retained read-permission check prevents targeting kernel-private memory or disclosing data - the realistic worst case is a reliable device halt/reboot (DoS) or a partly-controlled write into a user-read-only (P_RW_U_RO) memory-domain partition.

All signals converge on this being a genuine but moderate, locally-scoped issue rather than an internet-facing emergency. The CVSS vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H, 6.1) correctly reflects that exploitation requires an already-running unprivileged user-mode thread on the device that has been explicitly granted the RTIO context via rtio_access_grant() - this is local access with some pre-existing privilege, not a remote network attack. The dominant impact is Availability (A:H): any such thread can aim the out-parameters at globally-readable-but-unwritable flash (.text/.rodata), causing a supervisor-mode store fault that reaches z_fatal_error() and reliably halts or reboots the device (DoS). Integrity impact is limited (I:L): the attacker can deposit only partly-controlled values (a pointer-sized store and a 4-byte length) into memory a memory-domain partition marked K_MEM_PARTITION_P_RW_U_RO, bypassing that partition's user-level write protection. Confidentiality is correctly N - the retained read-permission check means kernel-private memory cannot be targeted and no data is disclosed. No EPSS score, no CISA KEV listing, and no public exploit were provided; absence of KEV/EPSS is expected for an embedded-RTOS flaw and is not itself a red flag. The practical priority is high for the specific population of devices running CONFIG_USERSPACE + CONFIG_RTIO_SYS_MEM_BLOCKS that expose RTIO to untrusted user threads, and low for everyone else, since the vulnerable code path is entirely absent without that configuration.

On a Zephyr device built with CONFIG_USERSPACE and CONFIG_RTIO_SYS_MEM_BLOCKS, a low-trust application thread that holds an RTIO access grant calls rtio_cqe_get_mempool_buffer() passing a completion-queue entry whose flags it fully controls and buff/buff_len pointers aimed at read-only memory (e.g. flash .rodata). The kernel verifier only checks read permission, so it proceeds and performs supervisor-mode stores through those pointers, faulting and triggering the default fatal-error handler to halt or reboot the device for a reliable denial of service; alternatively the thread targets a P_RW_U_RO partition to write past its own write protection. No public proof-of-concept was identified at time of analysis, but the attack is deterministic and requires no special timing.