CVE-2026-19737
Beschrijving NL
i2s_esp32_trigger_check() in drivers/i2s/i2s_esp32.c valideert de gevraagde richting alleen voor I2S_DIR_BOTH. De takken I2S_DIR_RX en I2S_DIR_TX lezen dev_cfg->rx.data->geconfigureerd / dev_cfg->tx.data->geconfigureerd zonder eerst de stroomaanwijzers te controleren. De device instantiation macro I2S_ESP32_STREAM_INIT() stelt zowel .conf als .data in op NULL voor een richting die de devicetree niet beschrijft, dus in een instantie die slechts één richting bedraadt — de normale vorm voor audio-uitvoer of een worldsemi, ws2812-i2s LED-strip — verwijdert de andere richting een NULL-AANWIJZER in plaats van een fout te retourneren. i2s_trigger() is een Zephyr syscall en z_vrfy_i2s_trigger() in drivers/i2s/i2s_handlers.c valideert alleen het apparaatobject en de aanwezigheid van de trigger API-aanwijzer; het dir-argument wordt niet gevalideerd doorgegeven aan de driver. Op een build met CONFIG_USERSPACE ingeschakeld, kan een thread in gebruikersmodus die aan het I2S-apparaat is toegekend, een enkele i2s_trigger() -oproep uitvoeren met de naam van de niet-bekabelde richting en een lading van adres 0 in kernelmodus veroorzaken. Onder de Espressif-onderdelen die deze driver dragen, is userspace alleen beschikbaar in de boom op RISC-V SoC's met CONFIG_RISCV_PMP, en v4.4.0 is de eerste release waar dat kan worden gebouwd: de ESP32-C6 HPCORE selecteert RISCV_PMP wanneer deze niet is gebouwd voor MCUboot. ESP32-C5 in v4.4.x heeft dezelfde PMP-regio en gebruikersruimte linker-ondersteuning, maar selecteert standaard niet RISCV_PMP. Espressif Xtensa-doelen ondersteunen Zephyr-gebruikersruimte niet en in een niet-gebruikersruimte-build kan de slechte richting alleen afkomstig zijn van in-kernel applicatiecode. De impact is beperkt tot beschikbaarheid: de toegang is een uitlezing op offset 0 van de ontbrekende stroomstructuur, dus er is geen door aanvallers gecontroleerde offset, geen schrijfprimitieve en geen informatieverschaffing. Met de standaard fatale fouthandler stopt de resulterende uitzondering het systeem, waardoor een onbevoorrechte gebruikersmodus-thread een systeembrede denial of service krijgt. De oplossing voegt dezelfde aanwijzercontrole toe die de I2S_DIR_both-tak al heeft uitgevoerd en retourneert -ENOSYS voor een richting die de instantie niet implementeert; de andere toegangspunten van de bestuurder (i2s_esp32_config_check(), i2s_esp32_config_get(), i2s_esp32_read(), i2s_esp32_write()) bewaakten de pointers al en een statische audit vond geen gelijkwaardig onbewaakt pad. Het defect van de driver is ouder dan het getroffen bereik. De onbewaakte dereferentie is aanwezig vanaf v4.2.0 (bereikt via i2s_esp32_trigger_stream(), wiens if (stream) guard het adres van een struct-lid test en nooit onwaar is) en neemt zijn huidige i2s_esp32_trigger_check() -formulier aan in v4.3.0. Geen Espressif-configuratie in de boom vóór v4.4.0 kan een thread in gebruikersmodus uitvoeren, dus in v4.2.x en v4.3.x kan het richtingargument alleen afkomstig zijn van vertrouwde kernelcode. Die releases dragen de bug, maar worden niet vermeld als aangetast; de fix is ook samengevoegd tot v4.3-tak als verharding.
Origineel (Engels) tonen
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.