CVE-2026-19737: NULL pointer dereference in the ESP32 I2S driver when triggering an unsupported direction
i2sesp32triggercheck() in drivers/i2s/i2sesp32.c validates the requested direction only for I2SDIRBOTH. The I2SDIRRX and I2SDIRTX branches read devcfg->rx.data->configured / devcfg->tx.data->configured without first checking the stream pointers. The device instantiation macro I2SESP32STREAMINIT() 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.
i2strigger() is a Zephyr syscall, and zvrfyi2strigger() in drivers/i2s/i2shandlers.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 CONFIGUSERSPACE enabled, a user-mode thread that has been granted the I2S device can issue a single i2strigger() 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 CONFIGRISCVPMP, and v4.4.0 is the first release where that is buildable: the ESP32-C6 HPCORE selects RISCVPMP 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 RISCVPMP 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 I2SDIRBOTH branch already performed and returns -ENOSYS for a direction the instance does not implement; the driver's other entry points (i2sesp32configcheck(), i2sesp32configget(), i2sesp32read(), i2sesp32write()) 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 i2sesp32triggerstream(), whose if (stream) guard tests the address of a struct member and is never false) and takes its present i2sesp32triggercheck() 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Zephyr I2S ESP32 driverto a version that resolves this vulnerability.Fixed in v4.3-branch
Event History
Frequently Asked Questions
Which deployments have an unprivileged exploitation path?
The described unprivileged path requires CONFIG_USERSPACE, a user-mode thread that has been granted access to the affected I2S device, and an ESP32 I2S instance whose devicetree describes only one stream direction. In-tree userspace support among the relevant Espressif parts is available only on RISC-V SoCs with CONFIG_RISCV_PMP.
What must an attacker do to trigger the failure?
A permitted user-mode thread can make one i2s_trigger() syscall and specify the direction that is not wired for that I2S instance. The syscall verifier validates the device and trigger API, but does not validate the direction before it reaches the driver.
How can I identify a susceptible I2S instance?
Check the devicetree configuration for ESP32 I2S devices that describe only RX or only TX. For such single-direction instances, the undescribed direction has NULL stream configuration and data pointers; examples given include audio-output and worldsemi,ws2812-i2s LED-strip configurations.
What can be done before a fix is deployed?
Do not grant affected I2S devices to user-mode threads, and ensure callers do not invoke i2s_trigger() with a direction that is not configured for the device. This removes the described user-mode syscall path to the kernel-mode NULL dereference.
What is the expected security impact?
The reported impact is availability only: triggering the condition causes a load from address 0 in kernel mode. The provided vector reports no confidentiality or integrity impact.