CVE-2026-80775 in Linux
Resumen
por VulDB • 2026-09-04
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
futex: Corregir una condición de carrera (race condition) en la asignación inicial de mm->futex.phash.ref
futex_hash_allocate() asigna mm->futex.phash.ref sin ningún bloqueo. El commit d9b05321e21e ("futex: Move futex_hash_free() back to __mmput()") movió la asignación aquí y asumió que el proceso tiene un solo hilo en este punto.
El commit ee9dce44362b ("futex: Drop CLONE_THREAD requirement for private default hash alloc") amplió need_futex_hash_allocate_default() para cubrir cualquier clon con CLONE_VM, pero excluyó vfork porque el padre está suspendido y no puede entrar en condición de carrera.
Esto ya no se cumple cuando vfork está anidado. Si un hijo creado mediante vfork llama a vfork nuevamente y luego es terminado con SIGKILL, el padre se libera de su espera por vfork y se ejecuta concurrentemente con el nieto en la misma mm (memoria compartida). Ninguno de ellos pasó por futex_hash_allocate_default().
Cuando ambos llaman a prctl(PR_FUTEX_HASH, PR_FUTEX_HASH_SET_SLOTS) al mismo tiempo, cada uno ve mm->futex.phash.ref como NULL y almacena su propio contador percpu. Solo sobrevive la última escritura. El contador almacenado primero ya no es accesible desde la mm, por lo que las referencias sobre él no son vistas por __futex_ref_atomic_end(). Un hash privado que aún tiene referencias se considera entonces muerto y se libera, y una tarea que todavía mantiene uno de sus buckets escribe en memoria liberada dentro de futex_q_lock().
Almacenar el contador una sola vez con cmpxchg() y permitir que el perdedor libere su propio recurso mediante free_percpu(). La referencia inicial debe tomarse antes del almacenamiento; de lo contrario, otra tarea puede instalar un hash privado mientras el contador sigue siendo 0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.