CVE-2026-19737
MediumCVSS 5.5Exploitation Probability (EPSS)
Low risk1th percentile - higher than 1% of all known CVEs
Summary
Vulnerability in the I2S driver for Espressif (ESP32) chips in Zephyr OS. The i2s_esp32_trigger_check() function does not validate stream pointers for RX/TX directions, leading to NULL dereference when only one direction is configured. An unprivileged user-mode thread can call i2s_trigger() with an unsupported direction and cause a kernel panic (denial of service).
Risk Assessment
The risk is a system-wide denial of service (DoS) triggered by an unprivileged user-mode thread, potentially halting the entire system. This affects builds with CONFIG_USERSPACE enabled on RISC-V SoCs (e.g., ESP32-C6) in Zephyr versions from 4.4.0.
Recommendation
Update Zephyr OS to a version containing the fix (merged in v4.4 and v4.3-branch). If updating is not possible, disable CONFIG_USERSPACE or restrict I2S device access to trusted kernel code only.
Other vulnerabilities in Zephyr OS
See all- CVE-2026-17052High
The Time-aware GPIO driver in Zephyr OS lacks validation of output pointers in the tgpio_pin_read_ts_ec() syscall, allowing an unprivileged thread to write to arbitrary kernel memory. The vulnerability only affects builds with CONFIG_USERSPACE=y and CONFIG_TIMEAWARE_GPIO=y, and practical exposure is limited by build issues in some versions.
- CVE-2026-15893Medium
In Zephyr OS, the net_if_ipv6_calc_reachable_time() function in subsys/net/ip/net_if.c incorrectly calculates the neighbor reachable time when base_reachable_time is 1, resulting in a value of 0. An attacker can send an unauthenticated Router Advertisement with the Reachable Time field set to 1, causing the reachable time to be zeroed. Consequently, when a neighbor is confirmed reachable, a kernel assertion may occur (if CONFIG_ASSERT is enabled) or the timer fires immediately, leading to constant re-solicitation and degradation of Neighbor Discovery.
- CVE-2026-13216Medium
The virtio PCI driver in Zephyr OS (drivers/virtio/virtio_pci.c) improperly validates the capability length (cap_len) read from PCI configuration space. The lack of runtime validation (assert is disabled in production builds) leads to an out-of-bounds write on the kernel stack during device initialization.
- CVE-2026-11809Low
The UpdateHub OTA client in Zephyr OS contains an uninitialized heap memory read and out-of-bounds read in z_impl_updatehub_probe(). A malicious UpdateHub server can send a crafted response that, after a failed first JSON parse, uses a non-NUL-terminated metadata_copy buffer, leading to a read past the allocated memory and potentially crashing the device.
- CVE-2026-11368High
A vulnerability in the ATT layer of the Bluetooth stack in Zephyr OS leads to a use-after-free of channel memory. When a remote device disconnects during ongoing ATT traffic, a deferred callback may reference a freed channel, causing a system crash or potential memory corruption.
- CVE-2026-10677Medium
In Zephyr OS (versions v1.12.0 through v4.4.1), the CONFIG_USERSPACE syscall verifier in z_vrfy_k_poll() does not free memory on validation failure. An attacker can repeatedly trigger a memory leak, exhausting the kernel pool and causing denial of service.
- CVE-2026-10674Medium
In Zephyr OS (since v2.5.0), the NXP LPUART driver disables peripheral clocks before validating configuration. Unsupported parameters cause an error without re-enabling the clock, leading to a hard fault and system crash.
- CVE-2026-10666High
A stack buffer overflow vulnerability exists in the parse_ipv4() function in Zephyr OS. An attacker can craft an IP address with a long suffix after the colon, causing data to be copied beyond the allocated 17-byte buffer. The issue has been present since v1.9.0 through v4.4.0 and can lead to system crashes or potential control-flow hijack.
- CVE-2026-10657Low
In Zephyr OS, a vulnerability in the DNS resolver uses memcmp() to always compare 7 bytes with the ".local" suffix, even when the final hostname label is shorter. This causes an out-of-bounds read past the string terminator, potentially leading to a page fault and denial of service (DoS). The flaw is present only when CONFIG_MDNS_RESOLVER is enabled and exists since v1.10.0.
- CVE-2026-10656Medium
The MAX32xxx USB device controller driver (udc_max32.c) in Zephyr OS does not check if the endpoint buffer is NULL in the OUT and IN transfer-completion handlers. When a USB host sends a new SETUP packet during an ongoing EP0 transfer, the FIFO can be drained, causing a stale event to be processed, leading to a near-NULL pointer dereference and device crash.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

