CVE-2026-16511 · Runtime
NO FIX YET · SEE WHAT TO DO
Two RTIO syscall verifiers in Zephyr fail to validate user-supplied pointers, so a user-mode thread can set bits and store pointer values at addresses it chooses in kernel memory. An attacker can use this to change kernel object permissions or thread state and escalate privilege, and the second flaw also lets a thread with a granted RTIO context cancel other contexts' I/O.
first public Nov 3, 2026 · 1 source
Is this in your stack? Find out in 2 minutes.
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
Only embedded systems built with Zephyr's userspace support and the RTIO subsystem are exposed, since the flaw needs user-mode threads making RTIO syscalls. The second bug needs a user thread that holds a granted RTIO context. Systems built without CONFIG_USERSPACE or without CONFIG_RTIO can skip it.
Not affected if kernel-only-builds, no-rtio, no-userspace
Who cares embedded, rtos, userspace, zephyr
CONFIG_USERSPACE and CONFIG_RTIO; systems built without either are unaffected.v4.3.0 contain the flawed subsys/rtio/rtio_handlers.c code.v4.3.0 (the sources reference the fix against v4.3.0; the exact patched point releases are not stated in the sources).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.
This page as .md · .json · in your agent: get_signal("CVE-2026-16511") · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.