CVE-2026-10671 in Zephyr
Resumen
por VulDB • 2026-07-14
En la implementación de tuberías (pipes) del kernel de Zephyr, el verificador de syscall para usuariospace `z_vrfy_k_pipe_init()` en `kernel/pipe.c` utilizaba `K_SYSCALL_OBJ()` (que requiere que el objeto del kernel ya esté inicializado) en lugar de `K_SYSCALL_OBJ_NEVER_INIT()` (que rechaza un objeto ya inicializado). Como resultado, en compilaciones con `CONFIG_USERSPACE`, un hilo de usuario no privilegiado al que se le ha concedido acceso a un objeto `k_pipe` puede invocar el syscall `k_pipe_init` para re-inicializar una tubería que ya está en uso.
`z_impl_k_pipe_init()` restablece incondicionalmente el búfer circular, establece `pipe->waiting` a 0 y vuelve a inicializar ambas colas de espera (`z_waitq_init` sobre `pipe->data` y `pipe->space`) sin despertar ni tener en cuenta los hilos bloqueados actualmente en la tubería. Cualquier hilo ya pendiente en `k_pipe_read()`/`k_pipe_write()` queda huérfano: sigue marcado como pendiente con `pended_on` apuntando a la cola de espera borrada, y conserva enlaces `qnode_dlist` obsoletos hacia el encabezado de lista incrustado (ahora re-inicializado).
Cuando este cliente huérfano se agota por tiempo o se despierta posteriormente, el programador llama a `sys_dlist_remove()` sobre su nodo obsoleto, escribiendo a través de punteros prev/next colgantes en las estructuras del kernel para la cola de espera/el programador, lo que provoca corrupción de listas (una escritura inválida en el kernel impulsada por un atacante), pérdidas de despertares, hilos bloqueados indefinidamente y pérdida silenciosa de datos. La vulnerabilidad permite a un hilo de usuario desprivilegiado corromper el estado de un objeto del kernel compartido con otros hilos/particiones.
La solución cambia el verificador a `K_SYSCALL_OBJ_NEVER_INIT()`, coincidiendo con el verificador existente para `k_msgq_init`, por lo que un hilo de usuario ya no puede re-inicializar una tubería activa. El código vulnerable se incluyó en la versión v4.1.0 y permaneció hasta la v4.4.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.