CVE-2026-16511
HighCVSS 8.8Exploitation Probability (EPSS)
Low risk7th percentile - higher than 7% of all known CVEs
Summary
Two RTIO syscall verifiers in Zephyr RTOS failed to properly validate user-supplied pointers before the kernel wrote through them. z_vrfy_rtio_sqe_cancel() performed no validation at all, allowing a user-mode thread to set chosen bits in kernel memory, while z_vrfy_rtio_sqe_copy_in_get_handles() wrote a kernel pointer to an arbitrary address without a write-permission check. Only systems built with CONFIG_USERSPACE and CONFIG_RTIO are affected.
Risk Assessment
A user-mode thread can modify fields in kernel data structures (such as object permissions or thread state), enabling privilege escalation, and can cancel I/O submissions belonging to other RTIO contexts.
Recommendation
Update Zephyr RTOS to a version containing the fixes (validate the out-parameter as writable, bound the cancel handle to real pool storage, and require permission on the owning RTIO context). Systems built without CONFIG_USERSPACE or CONFIG_RTIO are unaffected.
Other vulnerabilities in Zephyr RTOS
See all- CVE-2026-90585Medium
The Renesas RA SCI UART driver in Zephyr does not acknowledge the receive-error condition in uart_ra_sci_eri_isr() when no callback is registered (data->user_cb is NULL). The SCI error flags remain set and the ICU interrupt flag is never cleared, causing the ISR to re-pend immediately and re-enter endlessly. This occurs with CONFIG_UART_INTERRUPT_DRIVEN=y and CONFIG_UART_ASYNC_API=n when the error interrupt is unmasked by uart_configure() or uart_irq_err_enable().
- CVE-2026-87043Medium
In the entropy-device random number generator (subsys/random/random_entropy_device.c), rand_get() returned early with -ENODEV when device_is_ready() failed, bypassing the non-cryptographic system-timer fallback. Because sys_rand_get() and sys_rand32_get() return void and cannot report failure, the caller's output buffer was left untouched and its previous (uninitialized) contents were returned as random data. The not-ready state is a normal runtime condition (e.g., early initialization) or a permanent result of an entropy driver init failure.
- CVE-2026-87041High
A vulnerability in the RTIO submission-queue verifier rtio_vrfy_sqe() in Zephyr RTOS stems from incorrectly combining K_SYSCALL_MEMORY() results with &=; since the macro returns nonzero on failure, buffer permission checks were inverted. Inaccessible buffers were accepted while legitimate thread-owned buffers caused a kernel oops. This allows user threads with an RTIO context to write to arbitrary kernel memory, disclose it, or fault the kernel, bypassing CONFIG_USERSPACE isolation.
- CVE-2026-87039High
A vulnerability in the Zephyr RTOS syscall verifier z_vrfy_i2s_configure() skips the K_SYSCALL_OBJ ownership/type check for config.mem_slab and the block_size sanity check when frame_clk_freq is 0. As a result, an unprivileged thread under CONFIG_USERSPACE can supply an arbitrary pointer that reaches driver code (e.g., i2s_litex) and is used in supervisor context by k_mem_slab_alloc()/k_mem_slab_free().
- CVE-2026-82962Medium
A vulnerability in ethernet_fill_header() in the Zephyr RTOS network stack prepends the Ethernet header in place via net_buf_push without verifying that the packet has sufficient headroom. Packets allocated by a different L2 (e.g., 802.15.4/OpenThread, PPP) and handed to Ethernet through routing or tunnelling have too little (usually zero) headroom, causing an out-of-bounds write. In builds without CONFIG_ASSERT and CONFIG_NET_BUF_HARDENING this results in memory corruption.
- CVE-2026-19595Medium
A vulnerability in the Zephyr RTOS syscall verifier: z_vrfy_rtio_cqe_get_mempool_buffer() validated its output parameters buff and buff_len with K_SYSCALL_MEMORY_READ() instead of K_SYSCALL_MEMORY_WRITE(). This allows an unprivileged user-mode thread to invoke the syscall with pointers to read-only memory, causing a supervisor-mode store outside the permitted region or a kernel fault that halts or reboots the device.
- CVE-2026-19940Medium
A vulnerability in the Bluetooth Classic Hands-Free Profile Audio Gateway (HFP AG) implementation in Zephyr RTOS causes corruption of the kernel timeout list. By sending AT+CIND? and quickly reconnecting, a remote attacker can trigger a system-wide fault or hang.
- CVE-2026-19736High
The NXP MCUX TRNG entropy driver in Zephyr (drivers/entropy/entropy_mcux_trng.c) passes the caller's byte count directly to the SDK routine TRNG_GetRandomData(), which on i.MX RT5xx/RT6xx parts always copies whole 32-bit words and rounds entropy draws up to a multiple of 128 bytes. A request length not a multiple of four causes an underflow in the SDK's buffer-full check, leading to an overflow of up to 127 bytes past the caller's buffer.
- CVE-2026-19575High
A vulnerability in Zephyr RTOS affects the user-mode verification handler z_vrfy_device_deinit() in kernel/device.c, which validated its dev argument with K_SYSCALL_OBJ_INIT(dev, K_OBJ_ANY). Because k_object_validate() short-circuits type comparison for K_OBJ_ANY, the check only verified that the pointer was the base address of some kernel object the calling thread was granted, without comparing the object's actual type. This allows a local user-mode thread to pass a thread stack object (e.g., from k_thread_stack_alloc()) and achieve supervisor-mode kernel code execution.
- CVE-2026-19574High
In the ARM64 MMU back-end of Zephyr RTOS, address space identifiers (ASIDs) are assigned by a bare round-robin counter, which after wrapping past 255 possible values can hand the same ASID to a new domain while a still-live domain holds it. Because domain-private mappings are installed as non-global (MT_NG), the ASID is the only tag separating cached translations in the TLB, and the context-switch path does not flush the TLB for a duplicate reached through a third domain. As a result, user-mode threads in one domain can read and write memory belonging to another domain, defeating memory-domain isolation.
Original NVD description (English source)
Two RTIO syscall verifiers, in subsys/rtio/rtio_syscalls.c (subsys/rtio/rtio_handlers.c before v4.3.0), did not validate user-supplied pointers before the kernel wrote through them. z_vrfy_rtio_sqe_cancel() performed no validation at all. It passed the caller's struct rtio_sqe pointer straight to z_impl_rtio_sqe_cancel(), which converts it with CONTAINER_OF to a struct rtio_iodev_sqe, ORs RTIO_SQE_CANCELED (BIT(3)) into its 16-bit flags field in supervisor mode, then loads its next pointer and repeats until that pointer is NULL. The syscall takes no RTIO context argument, so it needs no object grant: any user-mode thread on a CONFIG_USERSPACE build can set that bit in a 16-bit word at an address of its choosing in kernel memory, and the kernel continues the write along whatever pointer chain it finds at the corresponding offset. Setting chosen bits in kernel data structures, such as object permission or thread state fields, can be used to escalate privilege from user mode. z_vrfy_rtio_sqe_copy_in_get_handles() validated its RTIO context and the input SQE array, but only NULL-checked the handle out-parameter before writing a kernel SQE pointer through it, with no K_SYSCALL_MEMORY_WRITE check. A user thread that holds a granted RTIO context can therefore make the kernel store a pointer value at an arbitrary address. The fixes validate the handle out-parameter as writable, bound the cancel handle to real submission-pool storage, and require permission on the RTIO context that owns the matching pool. Without that last check a bounded handle still let any user thread cancel submissions belonging to other contexts, silently aborting their I/O. Systems built without CONFIG_USERSPACE or without CONFIG_RTIO are unaffected.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS