CVE-2026-16513

HIGHPre-NVD 7.87.8—
EchelonGraph scoreMEDIUM confidence

This high-severity CVE scores 7.8 under a secondary CVSS source (NVD's own analysis pending). EPSS exploit probability: 0.1% (1st percentile of EPSS-scored CVEs). GitHub Security Advisory data not yet ingested — confidence will rise once GHSA publishes (typical lag: hours to days for open-source ecosystem CVEs; never for infrastructure-only CVEs).

Triggered by: NVD CVSS baseline
Sources: epss, secondary
Trending — 3 sources updated this week
7.8EG
EchelonGraph verdictPlan a fixSerious severity, but no confirmed exploitation yet.
  • High severity, but no confirmed exploitation yet
CISA-KEV: Not listedEPSS PROB: 0.1%CVSS: 7.8Exploit: None knownExposed services: Not assessed

A fix is available — apply it.

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.

CVSS v3
7.8
EG Score
7.8HIGHmedium confidence
EG Risk
35
EG Risk 35/100CISA SSVC

EG Risk is EchelonGraph's 0–100 priority score: it fuses intrinsic severity with real-world exploitation and automatability so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner. Distinct from the 0–10 EG Score (severity).

How it’s computed
Severity78% × 45%
Exploitation0% × 40%
Automatability0% × 15%
CISA SSVC: Track at low or medium mission impact; Track* at high (mission-essential systems).
Action: A fix is available. Apply it within your standard update timelines.
EPSS PROB
0.1%
EPSS %ILE
1st
KEV
Not listed

CISA SSVCTrack at low or medium mission impact; Track* at high (mission-essential systems).

A fix is available. Apply it within your standard update timelines.

Exploitation none (CISA Vulnrichment) · Automatable no (CISA Vulnrichment) · Technical impact total (CISA Vulnrichment). Mission impact is CISA's Mission & Well-being decision point, and only you can judge it: high means the affected system is essential to your organisation's mission, or its compromise could cause irreversible harm to people. CISA's decision table

Published

September 28, 2026

Last Modified

September 30, 2026

Advisory Details (2)

Auto-updated Sep 28, 2026
🔬 Proof of concept available. Patch available. Sources: github_commit, github.
github Patch Available🟡 PoC Available

Missing write validation of user-supplied handle pointer in the RTIO syscall verifier allows arbitrary kernel write · Advisory · zephyrproject-rtos/zephyr · GitHub

https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-fwmc-q8qg-jcxq
github_commit

commit 95c355c42576 (zephyrproject-rtos/zephyr)

Fix landed in zephyrproject-rtos/zephyr commit 95c355c42576 — awaiting tagged release

https://github.com/zephyrproject-rtos/zephyr/commit/95c355c425763fbe5e735b9ef54dacce2c4ce21f

Weakness Classification(1)

MITRE Common Weakness Enumeration — the root-cause categories this CVE belongs to.

Data Freshness Timeline

(refreshed 14× in last 7d / 14× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-10-03 15:39 UTCEG score recompute
  2. 2026-10-03 14:25 UTCEPSS rescore
  3. 2026-10-03 02:25 UTCEG score recompute
  4. 2026-10-02 00:02 UTCEG score recompute
  5. 2026-10-01 19:49 UTCEPSS rescore
  6. 2026-09-30 21:30 UTCEG score recompute
  7. 2026-09-30 20:27 UTCEG score recompute
  8. 2026-09-30 15:02 UTCEPSS rescore
  9. 2026-09-29 22:11 UTCEG score recompute
  10. 2026-09-29 15:20 UTCEPSS rescore
  11. 2026-09-29 10:42 UTCEG score recompute
  12. 2026-09-28 21:18 UTCEG score recompute
  13. 2026-09-28 20:26 UTCEG score recompute
  14. 2026-09-28 20:26 UTCMITRE cvelistV5first tracked

Frequently asked(5)

What is CVE-2026-16513?
CVE-2026-16513 is a high vulnerability published on September 28, 2026. The userspace verifier zvrfyrtiosqecopyingethandles() in subsys/rtio/rtiosyscalls.c (subsys/rtio/rtiohandlers.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…
When was CVE-2026-16513 disclosed?
CVE-2026-16513 was first published on September 28, 2026, with the most recent update on September 30, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-16513 actively exploited?
CVE-2026-16513 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 0.1% probability of exploitation in the next 30 days (1st percentile of EPSS-scored CVEs).
What is the CVSS score of CVE-2026-16513?
CVE-2026-16513 has a CVSS base score of 7.8 (a secondary CVSS source that NVD displays; NVD's own analysis pending).
How do I remediate CVE-2026-16513?
A fix for CVE-2026-16513 is available: update to the fixed version the vendor names in its advisory.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-16513

Explore →

Is Your Infrastructure Affected by CVE-2026-16513?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.