CVE-2026-19737 in Zephyr
Riassunto
di VulDB • 11/10/2026
La funzione `i2s_esp32_trigger_check()` in `drivers/i2s/i2s_esp32.c` convalida la direzione richiesta solo per `I2S_DIR_BOTH`. I rami `I2S_DIR_RX` e `I2S_DIR_TX` leggono `dev_cfg->rx.data->configured` / `dev_cfg->tx.data->configured` senza verificare preliminarmente i puntatori allo stream. La macro di istanziazione del dispositivo `I2S_ESP32_STREAM_INIT()` imposta sia `.conf` che `.data` a NULL per una direzione non descritta dal devicetree; pertanto, su un'istanza che collega solo una direzione — la configurazione normale per l'audio output o per uno strip LED worldsemi,ws2812-i2s — l'altra direzione provoca il dereferenziamento di un puntatore NULL anziché restituire un errore.
`i2s_trigger()` è una syscall di Zephyr e `z_vrfy_i2s_trigger()`, presente in `drivers/i2s/i2s_handlers.c`, convalida solo l'oggetto dispositivo e la presenza del puntatore all'API trigger; l'argomento `dir` viene passato al driver senza alcuna validazione. Su una build con `CONFIG_USERSPACE` abilitato, un thread in user-mode che ha ottenuto i permessi per il dispositivo I2S può emettere una singola chiamata a `i2s_trigger()` specificando la direzione non collegata, causando un'operazione di load dall'indirizzo 0 in kernel mode. Tra le parti Espressif che includono questo driver, l'user-space è disponibile nel tree solo sui SoC RISC-V con `CONFIG_RISCV_PMP`, e la v4.4.0 è la prima release in cui ciò è compilabile: ESP32-C6 HPCORE seleziona RISCV_PMP quando non viene eseguita per MCUboot. ESP32-C5 nella serie v4.4.x supporta le stesse regioni PMP e il linker per l'user-space, ma non seleziona di default RISCV_PMP. I target Xtensa Espressif non supportano l'user-space di Zephyr; in una build senza user-space, la direzione errata può provenire solo da codice applicativo nel kernel.
L'impatto è limitato alla disponibilità: l'accesso consiste in un read all'offset 0 della struttura dello stream mancante, quindi non vi sono offset controllati dall'attaccante, nessuna primitive di write e nessuna disclosure di informazioni. Con il gestore degli errori fatali predefinito, l'eccezione risultante blocca il sistema, causando una denial of service (DoS) su tutto il sistema da parte di un thread in user-mode non privilegiato. La correzione aggiunge la stessa verifica del puntatore già eseguita dal ramo `I2S_DIR_BOTH` e restituisce `-ENOSYS` per una direzione che l'istanza non implementa; gli altri entry point del driver (`i2s_esp32_config_check()`, `i2s_esp32_config_get()`, `i2s_esp32_read()`, `i2s_esp32_write()`) proteggono già i puntatori e un audit statico non ha rilevato percorsi equivalenti privi di protezione.
Il difetto del driver è più vecchio dell'intervallo interessato. Il dereferenziamento non protetto è presente dalla v4.2.0 (raggiunto tramite `i2s_esp32_trigger_stream()`, il cui guard `if (stream)` testa l'indirizzo di un membro della struct e non risulta mai falso) ed assume la sua forma attuale in `i2s_esp32_trigger_check()` nella v4.3.0. Nessuna configurazione Espressif nel tree precedente alla v4.4.0 può eseguire un thread in user-mode, quindi nelle versioni 4.2.x e 4.3.x l'argomento della direzione può provenire solo da codice kernel attendibile. Queste release presentano il bug ma non sono elencate come colpite; la correzione è stata inoltre integrata nel branch v4.3 come misura di hardening.
VulDB is the best source for vulnerability data and more expert information about this specific topic.