What is the CVSS score of CVE-2026-17052?

CVE-2026-17052 has a CVSS 3.1 base score of 7.8 (High). CVSS vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.1%.

How to fix or mitigate CVE-2026-17052?

Within 24 hours, inventory every product and downstream fork built on Zephyr RTOS and determine which have both CONFIG_USERSPACE=y and CONFIG_TIMEAWARE_GPIO=y, prioritising v3.5.0-based trees and any downstream fork that locally patched the affected source file to make it compile; confirm the exact upstream or fork version and obtain the vendor advisory fix release, since patch is available but the specific fixed version is not stated here. Within 7 days, apply the vendor-released fix to all in-scope builds, rebuild and reflash affected devices, and where a rebuild cannot be completed inside the window, remove CONFIG_TIMEAWARE_GPIO or withhold the TGPIO device object from unprivileged user-mode threads as a temporary reduction in attack surface. Within 30 days, verify that fleet and fielded-device telemetry confirms remediation, sweep downstream forks that diverged between v3.5.0 and the later repaired releases to confirm they are not carrying the faulty verification handler, and add configuration-manifest checks to the build pipeline so userspace-plus-time-aware-GPIO combinations trigger security review rather than shipping silently.

Zephyr RTOS CVE-2026-17052

EUVD-2026-84054 HIGH

Out-of-bounds Write (CWE-787)

2026-09-21 zephyr

Buffer Overflow Memory Corruption Intel Zephyr Zephyrproject

7.8

CVSS 3.1 · Vendor: zephyr

View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

Access

Run unprivileged user-mode thread with TGPIO capability
Delivery

Call tgpio_pin_read_ts_ec with forged output pointers
Exploit

Bypass missing memory-write validation
Execution

Driver stores 8-byte regs at kernel address
Persist

Corrupt kernel structures
Impact

Escalate thread to supervisor or crash

Vulnerability Assessment

Weakness	CWE CWE-787 ASVS 5.0 V15 - Secure Coding and Architecture Bounds checking, write limits MITRE ATT&CK 2 techniques across 2 tactics: Execution, Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. Sign in to read
Exploitation Conditions	Requires a Zephyr build compiled with both CONFIG_USERSPACE=y and CONFIG_TIMEAWARE_GPIO=y (Intel time-aware GPIO driver), and the attacker must already be a local unprivileged user-mode thread that has been granted access to the TGPIO device object - a narrow capability not intended to confer kernel-memory access. Exploitation is further limited by the build-breakage window: from v3.6.0 the affected file failed to compile (relocated <zephyr/syscall_handler.h>, removed Z_SYSCALL_* macros) until repaired after v4.4.0, so the realistically exposed population is v3.5.0 builds and downstream trees that locally fixed that breakage. No remote or network path exists; access is local only.
Impact	This is a genuine high-severity local privilege-escalation flaw, but its real-world reach is tightly bounded. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 7.8) is well-founded: a local user-mode thread already granted a narrow TGPIO device capability gains a controlled write-what-where primitive across the userspace/kernel boundary, credibly yielding supervisor privilege or a crash. No EPSS score, no CISA KEV listing, and no public exploit are present in the provided data - consistent with a newly disclosed, embedded-RTOS local bug rather than a widely-exploited internet-facing one. Signals do not conflict: local-only vector, a requirement for CONFIG_USERSPACE=y plus CONFIG_TIMEAWARE_GPIO=y plus the Intel driver, and a build-breakage window (v3.6.0 through post-v4.4.0) that means only v3.5.0 builds and downstream trees that locally repaired the breakage are actually exposed. Net: technically real and worth patching for affected embedded builds, but the practical attack surface is very small, so this is a targeted/configuration-specific concern rather than a broad emergency.
Exploit ScenarioDerived	On a Zephyr build compiled with CONFIG_USERSPACE=y and CONFIG_TIMEAWARE_GPIO=y (Intel time-aware GPIO), an unprivileged user-mode thread that has been granted access to the TGPIO device object calls tgpio_pin_read_ts_ec() with attacker-chosen timestamp and event_count output pointers. Because z_vrfy_tgpio_pin_read_ts_ec() omits the K_SYSCALL_MEMORY_WRITE() checks its sibling handlers perform, the Intel driver executes two 8-byte supervisor-mode stores at those addresses, corrupting kernel data structures to escalate to supervisor privilege or crash the system. No public exploit code is identified at time of analysis, though the vendor commit and advisory pinpoint the exact primitive.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).

Patch available 0.1% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Sep 21, 2026

Local privilege escalation in Zephyr RTOS allows an unprivileged user-mode thread that holds access to the Intel time-aware GPIO (TGPIO) device object to perform two uncontrolled 8-byte supervisor-mode writes to attacker-chosen kernel addresses via the tgpio_pin_read_ts_ec() syscall. The syscall's verification handler omitted the K_SYSCALL_MEMORY_WRITE() check that the sibling handlers in the same file already perform, converting a benign timestamp read-back into a write-what-where primitive that can corrupt kernel data structures, escalate the calling thread to supervisor privilege, or crash the system. Exposed builds are narrow: CONFIG_USERSPACE=y and CONFIG_TIMEAWARE_GPIO=y must both be set, and because the affected source file failed to compile from v3.6.0 until after it was repaired past v4.4.0, the realistically exposed population is v3.5.0 builds plus downstream trees that locally patched that build breakage; no public exploit code has been identified at time of analysis and the flaw is not confirmed actively exploited (CISA KEV), though it is rated CVSS 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).

RemediationAI

Apply the upstream fix, commit 26264fffc17c2174319394ffa274af3f6efdc221 (https://github.com/zephyrproject-rtos/zephyr/commit/26264fffc17c2174319394ffa274af3f6efdc221), which is the patch referenced by advisory GHSA-8qw6-x76h-8mpc (https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-8qw6-x76h-8mpc); it adds K_OOPS(K_SYSCALL_MEMORY_WRITE(timestamp, sizeof(uint64_t))) and K_OOPS(K_SYSCALL_MEMORY_WRITE(event_count, sizeof(uint64_t))) to z_vrfy_tgpio_pin_read_ts_ec() in drivers/timeaware_gpio/timeaware_gpio_handlers.c. Patch availability is upstream fix available (PR/commit); a released patched version number is not independently confirmed from the supplied data, so downstream integrators should backport the two-line change to their own tree rather than assume a tagged release contains it. Because the flaw requires a local unprivileged thread that has already been granted access to the TGPIO device object, the most direct compensating controls are configuration-level: remove CONFIG_USERSPACE=y so the syscall verification path and the unprivileged-thread boundary do not exist (trade-off: eliminates Zephyr's userspace isolation entirely and is not acceptable for products that rely on it), or disable CONFIG_TIMEAWARE_GPIO=y (trade-off: loses Intel time-aware GPIO timestamping functionality, but the driver is platform-specific and many deployments do not use it). If the driver is required, tighten the device object's access policy so that only trusted threads with no other privilege needs can reach the TGPIO device object - this reduces but does not eliminate the attack surface, since any authorized thread retains the write-what-where primitive until the handler is patched - and audit downstream forks for local repairs to the post-v3.6.0 build breakage, which are precisely the trees most likely to be running an unpatched handler.

Affected VersionsENISA

Zephyr 3.5.0 <4.4.2

Affected Packages

euvd zephyr fix: 4.4.2

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Zephyr's syscall verification layer (z_vrfy_* handlers, generated from __syscall declarations) is the security boundary that enforces userspace/kernel separation when CONFIG_USERSPACE=y. A handler must validate every pointer argument supplied by the calling user-mode thread before dereferencing it in supervisor mode; K_SYSCALL_MEMORY_WRITE()/K_SYSCALL_MEMORY_READ() are the canonical checks used for that purpose. In drivers/timeaware_gpio/timeaware_gpio_handlers.c, z_vrfy_tgpio_pin_read_ts_ec() validated only the struct device *port object and forwarded the caller-supplied uint64_t *timestamp and uint32_t *event_count output pointers without those checks, even though z_vrfy_tgpio_port_get_time() and z_vrfy_tgpio_port_get_cycles_per_second() in the same file did. Because tgpio_pin_read_ts_ec() is declared __syscall, an unprivileged thread granted access to the TGPIO device object could pass arbitrary pointer values. tgpio_intel_read_ts_ec() in drivers/timeaware_gpio/timeaware_gpio_intel.c bounds-checks only the pin index and then unconditionally executes '*timestamp = <hardware time capture>' and '*event_count = <event counter>', i.e. two 8-byte stores in supervisor mode at fully attacker-selected addresses. This is an out-of-bounds/write-what-where defect in the CWE-787 family (the stored values are hardware register contents, so the primitive is a constrained write rather than an arbitrary byte copy, but the target address is unconstrained). The upstream fix, commit 26264fffc17c2174319394ffa274af3f6efdc221, inserts K_OOPS(K_SYSCALL_MEMORY_WRITE(timestamp, sizeof(uint64_t))) and K_OOPS(K_SYSCALL_MEMORY_WRITE(event_count, sizeof(uint64_t))) into the handler ahead of the driver call. Compounding the exposure, the affected file referenced a relocated header (<zephyr/syscall_handler.h>) and removed Z_SYSCALL_* macros from v3.6.0 onward, so the configuration simply did not build until that breakage was repaired after v4.4.0 - meaning only v3.5.0 and downstream trees carrying local fixes for that breakage compile an exploitable handler.

Know when Zephyr gets its next vulnerability

Watch products and get an email when something new is published
Check this CVE against your own stack and servers
Exploit and PoC references, threat intelligence from 22 sources

Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

Vendor (zephyr) PRIMARY 7.8 HIGH

AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

vuln.today AI 7.8 HIGH

Local user-mode thread (AV:L) needs only a granted TGPIO device capability (PR:L), no user interaction; the reliable write-what-where enables supervisor escalation, giving full C/I/A impact.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (zephyr).

CVSS VectorVendor: zephyr

Attack Vector

Local

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

DescriptionCVE.org

The Time-aware GPIO syscall verification handler z_vrfy_tgpio_pin_read_ts_ec() in drivers/timeaware_gpio/timeaware_gpio_handlers.c validated only the port device object and passed the caller-supplied timestamp and event_count output pointers to the driver without a K_SYSCALL_MEMORY_WRITE() check. The other handlers in the same file (z_vrfy_tgpio_port_get_time(), z_vrfy_tgpio_port_get_cycles_per_second()) already performed that check, so the omission left one syscall unguarded.

tgpio_pin_read_ts_ec() is declared __syscall, so with CONFIG_USERSPACE=y an unprivileged user-mode thread that has been granted access to the TGPIO device object can invoke it with arbitrary pointer values. tgpio_intel_read_ts_ec() in drivers/timeaware_gpio/timeaware_gpio_intel.c bounds-checks only the pin index and then unconditionally performs timestamp = ... and event_count = ..., executing two 8-byte stores in supervisor mode at addresses chosen by the user-mode caller.

The result is a write-what-where primitive that crosses the userspace/kernel boundary: the target address is fully attacker-chosen and the stored values are the hardware time-capture and event-counter register contents. Corrupting kernel data structures this way can escalate the calling thread to supervisor privilege or crash the system; the device-object permission required is a narrow capability that is not intended to confer any kernel-memory access. The fix adds the two missing K_SYSCALL_MEMORY_WRITE() validations before the driver call.

Exposure is narrow in practice. Only builds with CONFIG_USERSPACE=y and CONFIG_TIMEAWARE_GPIO=y compile the affected file, and from v3.6.0 onward the file additionally referenced a relocated header (<zephyr/syscall_handler.h>) and removed Z_SYSCALL_* macros, so such a configuration failed to build until those were repaired after v4.4.0. Downstream trees that locally corrected that breakage, and v3.5.0 builds where it did not exist, are the exposed population.

Technical POC Analysis

Assigned CWE-787; the underlying defect is a missing validation of user-supplied pointers, not a buffer boundary computation.

Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.

Executive ViewAI

Why It Matters

A high-severity flaw in the Zephyr RTOS (CVE-2026-17052) lets an unprivileged user-mode thread that has been granted access to the Intel time-aware GPIO device object write attacker-chosen values into kernel memory, potentially elevating itself to supervisor privilege or crashing the device. Only builds that enable both userspace support and time-aware GPIO are exposed, which in practice means v3.5.0 builds and downstream forks that locally repaired the affected file's compile breakage, so the impacted population is narrow but includes long-lived embedded products. Leadership should care because success yields full supervisor-level control of the device's most trusted execution context, defeating the isolation boundary that product hardening and certification claims rest on.

Business Impact: Medium

Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score

0.1%

Top 98% exploitable

Prevalence

Low

Popular RTOS but flaw gated to niche Intel time-aware-GPIO userspace builds

Data Quality

6 sources

Confidence: High

EUVD

NVD

CVE.org

EPSS

Vulnrichment

GitHub

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue

Severity HIGH

CISA KEV No

Public POC No

EPSS 0.1%

Patch available Yes

Active threat No

Deciding rule

HIGH severity (CVSS 7.0-8.9)

What every action level means

Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.

Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.

This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.

This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.

Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision

Defer

Exploitation

None

System Exposure· derived

Small

Automatable

Human Impact

Medium

Technical Impact

Total

Priority Score

Low Medium High Critical

KEV: 0

EPSS: 0

CVSS: +39

PoC: 0

Weaponized: 0

Threat intel: 0

Gov advisory: 0

Attack Technique

Buffer Overflow HIGH

A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.

Memory Corruption HIGH

Memory corruption occurs when a program writes data beyond the boundaries of allocated memory regions or accesses memory in unintended ways, violating the integrity of the process's address space.