Description
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.
Published: 2026-09-28
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: Kernel memory corruption and privilege escalation
Action: Immediate Patch
AI Analysis

Impact

The vulnerability is an out‑of‑bounds write in the RTIO syscall verifier that stores a user‑supplied pointer into kernel memory without validation. This creates a write‑what‑where primitive that writes a pointer to attacker‑controlled data at any kernel address, allowing overwriting of function pointers, thread structures or memory‑domain tables. The result is reliable kernel memory corruption and a path to compromise kernel integrity, potentially leading to privilege escalation from user mode to kernel mode.

Affected Systems

Zephyr RTOS builds that enable both CONFIG_USERSPACE and CONFIG_RTIO are affected. The flaw existed before the patch commit 95c355c425… and is present only when the RTIO subsystem is compiled with userspace support; builds lacking CONFIG_USERSPACE do not include the vulnerable verifier.

Risk and Exploitability

With a CVSS score of 7.8, the vulnerability presents a moderate‑high severity. The EPSS score is not available, but the vulnerability is not listed in CISA KEV, indicating no known widespread exploitation yet. An attacker does not need elevated rights; the ability to call RTIO APIs (e.g., sensor_read_async_mempool or async ADC helpers) is sufficient. The likely attack vector is a local unprivileged user executing the vulnerable syscall from user mode.

Generated by OpenCVE AI on September 28, 2026 at 21:41 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade Zephyr to the latest release that incorporates commit 95c355c425… or merge the patch that adds the K_SYSCALL_MEMORY_WRITE check.
  • Rebuild the RTIO handler components with the updated code, ensuring CONFIG_USERSPACE and CONFIG_RTIO remain enabled but now guarded by the new memory‑write validation.
  • If an immediate update is not possible, disable the RTIO subsystem (CONFIG_RTIO= n) in the kernel configuration to remove the vulnerable API surface.

Generated by OpenCVE AI on September 28, 2026 at 21:41 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 30 Sep 2026 21:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'total'}, 'version': '2.0.3'}

Mon, 28 Sep 2026 22:15:00 +0000

Type Values Removed Values Added
First Time appeared Zephyrproject
Zephyrproject zephyr
Vendors & Products Zephyrproject
Zephyrproject zephyr

Mon, 28 Sep 2026 20:30:00 +0000

Type Values Removed Values Added
Description 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.
Title Missing write validation of user-supplied handle pointer in the RTIO syscall verifier allows arbitrary kernel write
Weaknesses CWE-787
References
Metrics cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}

Subscriptions

Zephyrproject Zephyr
cve-icon MITRE

Status: PUBLISHED

Assigner: zephyr

Published:

Updated: 2026-09-30T20:11:11.980Z

Reserved: 2026-07-21T21:42:58.503Z

Link: CVE-2026-16513

cve-icon Vulnrichment

Updated: 2026-09-30T19:45:53.723Z

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-09-28T21:17:16.910

Modified: 2026-09-30T21:17:09.750

Link: CVE-2026-16513

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-28T22:00:09Z

Weaknesses