ZephyrProject Zephyr up to 4.4.1 RTIO Syscall Verification rtio_syscalls.c z_vrfy_rtio_sqe_copy_in_get_handles handle privileges management

Summaryinfo

A vulnerability was found in ZephyrProject Zephyr up to 4.4.1. It has been rated as very critical. This issue affects the function z_vrfy_rtio_sqe_copy_in_get_handles of the file subsys/rtio/rtio_syscalls.c of the component RTIO Syscall Verification. The manipulation of the argument handle leads to privileges management. This vulnerability is listed as CVE-2026-16513. The attack must be carried out locally. There is no available exploit. Upgrading the affected component is advised.

Detailsinfo

A vulnerability was found in ZephyrProject Zephyr up to 4.4.1. It has been rated as very critical. This issue affects the function z_vrfy_rtio_sqe_copy_in_get_handles of the file subsys/rtio/rtio_syscalls.c of the component RTIO Syscall Verification. The manipulation of the argument handle with an unknown input leads to a privileges management vulnerability. Using CWE to declare the problem leads to CWE-269. The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor. Impacted is confidentiality, integrity, and availability. The summary by CVE is:

The userspace verifier z_vrfy_rtio_sqe_copy_in_get_handles() in subsys/rtio/rtio_syscalls.c (subsys/rtio/rtio_handlers.c before v4.3.0) validated the RTIO object handle and the sqes input array, but not the handle out-parameter. On the first loop iteration it executed *handle = sqe, storing the kernel address of the newly acquired submission-queue entry through a pointer taken verbatim from user mode, with no K_SYSCALL_MEMORY_WRITE check in front of it. Any user-mode thread that has been granted a struct rtio kernel object can invoke the syscall with an arbitrary address in handle. That is the ordinary way an unprivileged thread uses the RTIO API, for example via sensor_read_async_mempool() or the async ADC helpers, which call rtio_sqe_copy_in_get_handles() internally. The store happens in supervisor mode before any submission-entry validation, so it fires regardless of whether the SQE contents are subsequently rejected. Only builds with CONFIG_USERSPACE and CONFIG_RTIO are affected; without CONFIG_USERSPACE the verifier is not compiled and the caller is already privileged. The write address is fully attacker-chosen and the written value is a pointer into the caller's own RTIO ring, whose contents the caller controls (the following *sqe = sqes[i] copies an attacker-supplied struct rtio_sqe into that slot). This yields a write-what-where primitive placing a pointer to attacker-controlled data at any kernel address, sufficient to corrupt kernel function pointers, thread structures, or memory-domain partition tables, and thus to escalate from user mode to kernel mode, defeating the isolation boundary CONFIG_USERSPACE is meant to enforce. At minimum it is a reliable kernel memory-corruption and crash primitive. The reporter reproduced the write on qemu_x86: a K_USER thread changed a supervisor global from NULL to a live kernel SQE pointer. The fix adds K_SYSCALL_MEMORY_WRITE(handle, sizeof(*handle)) (guarded by the existing optional-NULL semantics) before the loop, so the destination must lie in the calling thread's writable memory domain or the thread is terminated by K_OOPS. The neighbouring verifier z_vrfy_rtio_cqe_get_mempool_buffer(), which checked its buff/buff_len out-parameters only for read although the implementation writes through them, was hardened separately by bea93400138 ("rtio: syscalls: validate output params as writable"); that residual was materially weaker, since a read check still confines the target to the caller's own memory domain.

The advisory is shared at github.com. The identification of this vulnerability is CVE-2026-16513 since 07/21/2026. The exploitation is known to be easy. An attack has to be approached locally. Technical details are known, but no exploit is available. The price for an exploit might be around USD $0-$5k at the moment (estimation calculated on 09/28/2026). MITRE ATT&CK project uses the attack technique T1068 for this issue.

Upgrading to version 4.4.2 eliminates this vulnerability. Applying the patch 95c355c425763fbe5e735b9ef54dacce2c4ce21f is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Productinfo

Type

• Project Management Software

Vendor

• ZephyrProject

Name

• Zephyr

Version

• 4.4.0
• 4.4.1

CPE 2.3info

• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Discussion