Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.5",
  "pubDate": "2026-10-11T18:16:58.930Z",
  "pubdate": "2026-10-11T18:16:58.930Z",
  "executiveSummary": "A null pointer dereference vulnerability exists in the Zephyr RTOS drivers/i2s/i2s_esp32.c driver, affecting ESP32-C6 and ESP32-C5 SoCs running Zephyr v4.4.0 or later with userspace enabled.\nThe vulnerability occurs because i2s_esp32_trigger_check() fails to validate the presence of stream pointers when processing I2S_DIR_RX or I2S_DIR_TX requests.\nIf an I2S instance is configured for only one direction (e.g., transmit-only), a request for the missing direction results in a kernel-mode null pointer dereference.\nThis flaw can be exploited by an unprivileged user-mode thread that has been granted access to the I2S device, leading to a system-wide denial-of-service via an unhandled exception.\nThe risk is localized to availability, as the vulnerability is restricted to a read-at-offset-zero operation, precluding code execution or information disclosure primitives.\nThe issue is present in versions v4.2.0 through v4.4.x, though practical exploitation via userspace is only viable on platforms supporting RISCV_PMP/userspace integration (introduced in v4.4.0).",
  "technicalDetails": "The root cause of the vulnerability lies in the i2s_esp32_trigger_check() function within drivers/i2s/i2s_esp32.c. While the function correctly validates directions for I2S_DIR_BOTH, it fails to perform equivalent pointer validation for individual I2S_DIR_RX or I2S_DIR_TX requests.\nThe device instantiation macro I2S_ESP32_STREAM_INIT() assigns NULL to both .conf and .data pointers when a specific direction is not defined in the devicetree. When a user requests an unimplemented direction, the driver attempts to access members of the uninitialized/NULL structure, triggering an invalid memory access.\nThe attack vector involves the syscall interface i2s_trigger(), which invokes z_vrfy_i2s_trigger() in drivers/i2s/i2s_handlers.c. The handler validates the device object and the presence of the API pointer but fails to sanitize the 'dir' argument passed to the driver. Consequently, a user-mode thread can pass a malicious or unsupported direction argument to the underlying driver.\nIn systems where CONFIG_USERSPACE is enabled (e.g., ESP32-C6 HPCORE with CONFIG_RISCV_PMP), an unprivileged user-mode process can target the I2S device. By issuing an i2s_trigger() call for an unwired direction, the user forces the kernel to execute a load instruction from address 0x0.\nBecause the exception occurs in kernel mode, the Zephyr kernel triggers a fatal error, resulting in a system halt and a complete denial-of-service. There is no attacker-controlled offset, write primitive, or information disclosure mechanism; the impact is strictly limited to an availability failure.\nHistorically, this defect dates back to v4.2.0, where i2s_esp32_trigger_stream() contained an ineffective guard that tested the address of a struct member rather than the pointer value itself. While versions prior to v4.4.0 contain the vulnerable code, the lack of userspace support effectively mitigated the attack vector to trusted kernel-side callers."
}