CVE-2026-19737 in Zephyr
Resumen
por VulDB • 2026-10-11
i2s_esp32_trigger_check() en drivers/i2s/i2s_esp32.c valida la dirección solicitada únicamente para I2S_DIR_BOTH. Las ramas I2S_DIR_RX e I2S_DIR_TX leen dev_cfg->rx.data->configured / dev_cfg->tx.data->configured sin verificar primero los punteros de stream. La macro de instanciación del dispositivo I2S_ESP32_STREAM_INIT() establece tanto .conf como .data a NULL para una dirección que el árbol de dispositivos (devicetree) no describe, por lo que en una instancia que conecta solo una dirección — la forma normal para salida de audio o una tira LED worldsemi,ws2812-i2s — la otra dirección desreferencia un puntero NULL en lugar de devolver un error.
i2s_trigger() es una syscall de Zephyr, y z_vrfy_i2s_trigger() en drivers/i2s/i2s_handlers.c valida únicamente el objeto del dispositivo y la presencia del puntero a la API trigger; el argumento dir se pasa al controlador sin validar. En un compilado con CONFIG_USERSPACE habilitado, un hilo en modo usuario que haya recibido permisos para el dispositivo I2S puede emitir una única llamada i2s_trigger() indicando la dirección no conectada y provocar una carga desde la dirección 0 en modo kernel. Entre las partes de Espressif que llevan este controlador, el espacio de usuarios está disponible dentro del árbol (in-tree) únicamente en SoCs RISC-V con CONFIG_RISCV_PMP, y v4.4.0 es la primera versión donde esto se puede compilar: ESP32-C6 HPCORE selecciona RISCV_PMP cuando no se construye para MCUboot. ESP32-C5 en las versiones 4.4.x lleva el mismo soporte de regiones PMP y del enlace (linker) para espacio de usuarios, pero no selecciona RISCV_PMP por defecto. Los objetivos Xtensa de Espressif no admiten el espacio de usuarios de Zephyr, y en un compilado sin espacio de usuarios, la dirección incorrecta solo puede provenir de código de aplicación dentro del kernel.
El impacto se limita a la disponibilidad: el acceso es una lectura en el desplazamiento 0 de la estructura de stream faltante, por lo que no hay un desplazamiento controlado por el atacante, ni primitiva de escritura ni divulgación de información. Con el manejador de errores fatal predeterminado, la excepción resultante detiene el sistema, proporcionando a un hilo en modo usuario sin privilegios una denegación de servicio (DoS) para todo el sistema. La corrección añade la misma comprobación de punteros que ya realizaba la rama I2S_DIR_BOTH y devuelve -ENOSYS para una dirección que la instancia no implementa; los otros puntos de entrada del controlador (i2s_esp32_config_check(), i2s_esp32_config_get(), i2s_esp32_read(), i2s_esp32_write()) ya protegían los punteros, y un auditoría estática no encontró caminos equivalentes sin protección.
El defecto del controlador es anterior al rango afectado. La desreferencia sin protección está presente desde v4.2.0 (accedida a través de i2s_esp32_trigger_stream(), cuya guardia if (stream) prueba la dirección de un miembro de struct y nunca es falsa) y adopta su forma actual en i2s_esp32_trigger_check() en v4.3.0. Ninguna configuración de Espressif dentro del árbol anterior a v4.4.0 puede ejecutar un hilo en modo usuario, por lo que en las versiones 4.2.x y 4.3.x el argumento direction solo puede provenir de código kernel confiable. Esas releases llevan el bug pero no se listan como afectadas; la corrección también se ha fusionado a v4.3-branch como endurecimiento (hardening).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.