EUVD-2026-97105Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain user-mode thread with granted I2S access
-
ExploitInvoke i2s_trigger() naming the unwired direction
-
ExecutionKernel reads NULL stream pointer at offset 0
-
ImpactFatal exception halts entire system
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A10:2025 - Mishandling of Exceptional Conditions
ASVS 5.0
V16 - Security Logging and Error Handling Null pointer safety, defensive checks
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires a Zephyr v4.4.0 or later build for a RISC-V Espressif SoC (in-tree, the ESP32-C6 HPCORE which selects CONFIG_RISCV_PMP when not built for MCUboot) compiled with CONFIG_USERSPACE enabled; the I2S device instance must describe only one direction in devicetree (the normal shape for audio output or a worldsemi,ws2812-i2s LED strip), leaving the other direction's .conf/.data as NULL. A local user-mode thread must have been granted the I2S device object, after which a single i2s_trigger() call naming the unwired direction triggers the NULL read. Limiting factors that reduce real-world exposure: Espressif Xtensa targets do not support Zephyr userspace at all; ESP32-C5 carries the PMP/userspace support but does not select RISCV_PMP by default; and in any non-userspace build the bad direction can only originate from trusted in-kernel application code, so v4.2.x/v4.3.x (which contain the defect) are not exploitable by an untrusted actor. |
| Impact | This is a genuine but narrowly-scoped availability issue, not a high-urgency priority. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 5.5 Medium) is internally consistent with the description: exploitation is local (a user-mode thread on the device), requires low privileges (the thread must have been granted the I2S device object), and impacts availability only. No EPSS score was provided, so statistical exploitation probability cannot be weighed. The CVE is NOT listed in CISA KEV and no public exploit code is referenced - only a fix commit and a GHSA advisory are present. No SSVC decision data (exploitation status, automatable, technical impact) was supplied in the input. On the available signals this is a non-automatable, local, availability-only NULL-pointer dereference (CWE-476) affecting a specific build configuration; it should be patched during normal maintenance rather than treated as an emergency. The one notable caveat is a privilege-boundary consideration: an unprivileged user-mode thread can halt the entire kernel, which is more serious than a typical in-process crash, but it still requires that the local thread already be granted the device and that the build use a vulnerable configuration. |
| Exploit ScenarioDerived | On a Zephyr v4.4.0+ build for an ESP32-C6 (RISC-V, CONFIG_USERSPACE + CONFIG_RISCV_PMP) where the I2S device wires only one direction - e.g. an audio output or a worldsemi,ws2812-i2s LED strip - a low-privilege user-mode thread that has been granted the I2S device issues a single i2s_trigger() call naming the unwired direction (RX or TX). The driver dereferences a NULL stream pointer in kernel mode, and the default fatal-error handler halts the system, producing a system-wide denial of service. No public exploit code is identified; the attack is local and requires only low privileges (AV:L/PR:L). |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 11, 2026
System-wide denial of service can be triggered on Zephyr RTOS v4.4.0 or later builds for RISC-V Espressif SoCs (in-tree, the ESP32-C6 HPCORE) when CONFIG_USERSPACE is enabled: a local user-mode thread that has been granted the I2S device (PR:L) can issue a single i2s_trigger() call naming a direction the devicetree does not describe, causing a NULL pointer dereference in kernel mode (CWE-476). The impact is availability only-a NULL read with no attacker-controlled offset, no write primitive, and no information disclosure-but the default fatal-error handler halts the system, so an enabled user-mode thread can effect a system-wide denial of service. No public exploit code identified at time of analysis, and this is not confirmed actively exploited; real-world exposure is narrow because Xtensa Espressif targets do not support Zephyr userspace, ESP32-C5 does not select CONFIG_RISCV_PMP by default, and non-userspace builds can only pass the bad direction from trusted in-kernel code.
RemediationAI
Vendor patch is available per the advisory as commit 0d82dbbe72f154de32cc45021a9f59d9a737246b (upstream fix available; released patched version not independently confirmed), which adds the missing !dev_cfg->rx.conf || !dev_cfg->rx.data (and TX equivalent) check and returns -ENOSYS for a direction the instance does not implement; the advisory is GHSA-5g9q-h8wq-rrf3. Apply that commit or a later release containing it to Zephyr v4.4.0+ builds, including the v4.3-branch hardening merge. If immediate patching is not possible, the most direct compensating control is to avoid granting the I2S device object to user-mode threads on affected RISC-V Espressif SoCs-side effect: user-mode applications lose I2S access and must be redesigned to run in kernel mode. Alternatively, define both I2S directions in devicetree for each instance so the stream pointers are initialized, at the cost of potentially requiring extra pinmux, DMA, and clock resources and not always being feasible for a one-directional audio output or WS2812-I2S strip. Disabling CONFIG_USERSPACE prevents the user-mode reachable path but eliminates Zephyr's userspace isolation for the entire image and is a heavy trade-off. On non-RISC-V Espressif targets (Xtensa), and in any non-userspace build, the bad direction can only originate from trusted in-kernel code, so no untrusted-user mitigation is required there; ESP32-C5 does not select CONFIG_RISCV_PMP by default, which limits exposure on that part unless that option is explicitly enabled. There is no vendor-released patch version identified at time of analysis beyond the commit reference.
Affected VersionsENISA
Affected Packages
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
The affected code is Zephyr RTOS's I2S driver for Espressif SoCs (drivers/i2s/i2s_esp32.c). i2s_esp32_trigger_check() validates the requested direction only for I2S_DIR_BOTH; for I2S_DIR_RX and I2S_DIR_TX it reads dev_cfg->rx.data->configured / dev_cfg->tx.data->configured without first checking that the stream pointers are non-NULL. The I2S_ESP32_STREAM_INIT() macro sets both .conf and .data to NULL for a direction the devicetree does not describe, so an instance wired for only one direction-the normal shape for audio output or a worldsemi,ws2812-i2s LED strip-leaves the other direction's pointers NULL, and the unchecked read dereferences address 0. The path is reachable from user mode because i2s_trigger() is a Zephyr syscall and z_vrfy_i2s_trigger() in drivers/i2s/i2s_handlers.c validates only the device object and the presence of the trigger API pointer, passing the dir argument to the driver unvalidated. On a CONFIG_USERSPACE build, a user-mode thread granted the I2S device can therefore cause a kernel-mode load from address 0. Among Espressif parts carrying this driver, in-tree Zephyr userspace is available only on RISC-V SoCs with CONFIG_RISCV_PMP, and v4.4.0 is the first release where that is buildable: the ESP32-C6 HPCORE selects RISCV_PMP when not built for MCUboot, while ESP32-C5 in v4.4.x carries the PMP-region and userspace linker support but does not select RISCV_PMP by default; Xtensa Espressif targets do not support Zephyr userspace. The fix adds the same pointer check performed by the I2S_DIR_BOTH branch and returns -ENOSYS for a direction the instance does not implement. The driver's other entry points (i2s_esp32_config_check(), i2s_esp32_config_get(), i2s_esp32_read(), i2s_esp32_write()) already guarded these pointers, and a static audit found no equivalent unguarded path. The defect predates the affected range: the unguarded dereference is present from v4.2.0 via i2s_esp32_trigger_stream(), whose if (stream) guard tests the address of a struct member and is never false, and takes its present i2s_esp32_trigger_check() form in v4.3.0; v4.2.x and v4.3.x contain the bug but are not listed as affected because no in-tree Espressif configuration in those releases can run a user-mode thread, so the direction argument can only come from trusted kernel code there. CWE-476 (NULL Pointer Dereference) is the root-cause class.
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
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Local syscall from a granted unprivileged user-mode thread gives AV:L/PR:L/AC:L; impact is a kernel-halting crash, so A:H with C:N/I:N and S:U (kernel is both vulnerable and impacted component).
Primary rating from Vendor (zephyr).
CVSS VectorVendor: zephyr
DescriptionCVE.org
i2s_esp32_trigger_check() in drivers/i2s/i2s_esp32.c validates the requested direction only for I2S_DIR_BOTH. The I2S_DIR_RX and I2S_DIR_TX branches read dev_cfg->rx.data->configured / dev_cfg->tx.data->configured without first checking the stream pointers. The device instantiation macro I2S_ESP32_STREAM_INIT() sets both .conf and .data to NULL for a direction the devicetree does not describe, so on an instance that wires only one direction - the normal shape for audio output or a worldsemi,ws2812-i2s LED strip - the other direction dereferences a NULL pointer instead of returning an error.
i2s_trigger() is a Zephyr syscall, and z_vrfy_i2s_trigger() in drivers/i2s/i2s_handlers.c validates only the device object and the presence of the trigger API pointer; the dir argument is passed to the driver unvalidated. On a build with CONFIG_USERSPACE enabled, a user-mode thread that has been granted the I2S device can issue a single i2s_trigger() call naming the unwired direction and cause a load from address 0 in kernel mode. Among the Espressif parts that carry this driver, userspace is available in-tree only on RISC-V SoCs with CONFIG_RISCV_PMP, and v4.4.0 is the first release where that is buildable: the ESP32-C6 HPCORE selects RISCV_PMP when it is not built for MCUboot. ESP32-C5 in v4.4.x carries the same PMP-region and userspace linker support but does not select RISCV_PMP by default. Espressif Xtensa targets do not support Zephyr userspace, and in a non-userspace build the bad direction can only come from in-kernel application code.
The impact is limited to availability: the access is a read at offset 0 of the missing stream structure, so there is no attacker-controlled offset, no write primitive and no information disclosure. With the default fatal-error handler the resulting exception halts the system, giving an unprivileged user-mode thread a system-wide denial of service. The fix adds the same pointer check the I2S_DIR_BOTH branch already performed and returns -ENOSYS for a direction the instance does not implement; the driver's other entry points (i2s_esp32_config_check(), i2s_esp32_config_get(), i2s_esp32_read(), i2s_esp32_write()) already guarded the pointers, and a static audit found no equivalent unguarded path.
The driver defect is older than the affected range. The unguarded dereference is present from v4.2.0 (reached through i2s_esp32_trigger_stream(), whose if (stream) guard tests the address of a struct member and is never false) and takes its present i2s_esp32_trigger_check() form in v4.3.0. No in-tree Espressif configuration before v4.4.0 can run a user-mode thread, so in v4.2.x and v4.3.x the direction argument can only come from trusted kernel code. Those releases carry the bug but are not listed as affected; the fix has also been merged to v4.3-branch as hardening.
Threat Intelligence Overview
NVD
CVE.org
EPSS
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.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
A null pointer dereference occurs when a program attempts to access memory through a pointer that has been set to NULL (address 0x0).
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Potential off-by-one buffer overflow vulnerability in the Zephyr fuse file system. Rated critical severity (CVSS 10.0),
An out-of-bounds write in the Zephyr RTOS DNS resolver (dns_unpack_name()) lets a crafted DNS response corrupt memory on
Possible variant of CVE-2021-3434 in function le_ecred_reconf_req. Rated critical severity (CVSS 9.8), this vulnerabilit
Unchecked user input length in /subsys/net/l2/wifi/wifi_shell.c can cause buffer overflows. Rated critical severity (CVS
Potential buffer overflow vulnerability in the Zephyr CAN bus subsystem. Rated critical severity (CVSS 9.8), this vulner
Integer Underflow in 6LoWPAN IPHC Header Uncompression in Zephyr. Rated critical severity (CVSS 9.8), this vulnerability
Buffer overflow in Zephyr USB DFU DNLOAD. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable
DOS: Incorrect 802154 Frame Validation for Omitted Source / Dest Addresses. Rated critical severity (CVSS 9.8), this vul
zephyr-rtos version 1.12.0 contains a NULL base pointer reference vulnerability in sys_ring_buf_put(), sys_ring_buf_get(
Potential buffer overflow vulnerabilities n the Zephyr Bluetooth subsystem. Rated critical severity (CVSS 9.6), this vul
The documentation specifies that the BT_GATT_PERM_READ_LESC and BT_GATT_PERM_WRITE_LESC defines for a Bluetooth characte
Potential buffer overflows in the Bluetooth subsystem due to asserts being disabled in /subsys/bluetooth/host/hci_core.c
Exploit-DB