CVE-2026-19575 in Zephyr
Resumen
por VulDB • 2026-10-09
El controlador de verificación en modo usuario para la llamada al sistema `device_deinit()`, es decir, `z_vrfy_device_deinit()` en `kernel/device.c`, validaba su argumento `dev` con `K_SYSCALL_OBJ_INIT(dev, K_OBJ_ANY)`. Dado que `k_object_validate()` acorta (short-circuits) la comparación de tipos cuando el tipo solicitado es `K_OBJ_ANY`, la comprobación se reducía a: "este puntero es la dirección base de algún objeto del kernel al que el hilo llamante ha sido autorizado" — no se comparaba nunca el tipo real del objeto, y `K_SYSCALL_OBJ_INIT` también omitía la verificación del estado de inicialización. Los controladores hermanos `z_vrfy_device_init()` y `z_vrfy_device_is_ready()` ya utilizaban `K_OBJ_DRIVER_ANY` y no estaban afectados.
Por lo tanto, un hilo que se ejecuta en modo usuario puede pasar cualquier objeto del kernel sobre el cual tenga permisos — más útilmente, un objeto de pila de hilos obtenido mediante la llamada al sistema `k_thread_stack_alloc()` o una `K_THREAD_STACK` definida estáticamente a la que se le haya otorgado permiso para generar un hilo hijo en modo usuario — cuya memoria subyacente sea escribible desde el modo usuario. A continuación, `z_impl_device_deinit()` interpreta esos bytes escritos por el atacante como una estructura `device`: desreferencia el puntero de estado leído del objeto, llama al puntero de función leído de `ops.deinit` y, en caso de éxito, escribe a través de `state` nuevamente. El resultado es una llamada indirecta a una dirección arbitraria ejecutada en modo supervisor (supervisor mode), además de una lectura arbitraria del kernel y una escritura de un solo byte en el kernel.
La explotación otorga a un hilo local no privilegiado la ejecución completa de código en el kernel, anulando por completo la frontera de aislamiento `CONFIG_USERSPACE`; un intento menos preciso provoca una falla (fault) en modo supervisor y un bloqueo del sistema. El defecto es accesible únicamente en compilaciones que habilitan tanto `CONFIG_USERSPACE` como `CONFIG_DEVICE_DEINIT_SUPPORT`. Con el soporte de desinicialización deshabilitado, `z_impl_device_deinit()` devuelve `-ENOTSUP` sin llegar a desreferenciar nunca el puntero. En las versiones v4.2.x y v4.3.x, `CONFIG_DEVICE_DEINIT_SUPPORT` tenía por defecto valor "y" (activado), por lo que todas las compilaciones de `CONFIG_USERSPACE` de esas releases están expuestas a menos que la opción se deshabilitara explícitamente. A partir de la versión 4.4.0, la opción es opt-in (sin valor predeterminado y no seleccionada por ningún subsistema del árbol principal), por lo que una compilación v4.4.x solo está expuesta si habilita esta opción explícitamente. La línea v4.2 ya no se mantiene ni recibe backports.
La corrección cambia la comprobación de objetos a `K_OBJ_DRIVER_ANY`, lo que restringe el argumento al rango de tipos de objeto de controlador generado por la compilación (`K_OBJ_DRIVER_FIRST..K_LOBJ_DRIVER_LAST`) — las instancias reales de `struct device` colocadas por el enlazador (linker) —, de modo que los campos `state` y `ops.deinit` vuelven a estar bajo control del kernel.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.