Vulnerabilidad en kernel de Linux (CVE-2025-38554)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: se corrige un UAF cuando vma->mm se libera después de que vma->vm_refcnt se eliminara. Al inducir retrasos en los lugares adecuados, Jann Horn creó un reproductor para un problema de UAF difícil de alcanzar que se hizo posible después de que se permitiera reciclar los VMA agregando SLAB_TYPESAFE_BY_RCU a su caché. La descripción de la ejecución se tomó prestada del informe de descubrimiento de Jann: lock_vma_under_rcu() busca un VMA sin bloqueo con mas_walk() bajo rcu_read_lock(). En ese punto, el VMA puede liberarse simultáneamente y puede reciclarse por otro proceso. vma_start_read() luego incrementa vma->vm_refcnt (si está en un rango aceptable) y, si esto tiene éxito, vma_start_read() puede devolver un VMA reciclado. En este escenario, donde el VMA se ha reciclado, lock_vma_under_rcu() detectará el puntero ->vm_mm no coincidente y eliminará el VMA mediante vma_end_read(), que llama a vma_refcount_put(). vma_refcount_put() elimina el recuento de referencias y luego llama a rcuwait_wake_up() usando una copia de vma->vm_mm. Esto es incorrecto: asume implícitamente que quien llama mantiene activo el mm del VMA, pero en este escenario, quien llama no tiene relación con el mm del VMA, por lo que rcuwait_wake_up() puede causar UAF. El diagrama que representa la ejecución: T1 T2 T3 == == == lock_vma_under_rcu mas_walk mmap vma_start_read __refcount_inc_not_zero_limited_acquire munmap __vma_enter_locked refcount_add_not_zero vma_end_read vma_refcount_put __refcount_dec_and_test rcuwait_wait_event rcuwait_wake_up [UAF] Tenga en cuenta que rcuwait_wait_event() en T3 no se bloquea porque refcount ya fue descartado por T1. En este punto, T3 puede salir y liberar el mm que causa UAF en T1. Para evitar esto, movemos la verificación vma->vm_mm a vma_start_read() y tomamos vma->vm_mm para estabilizarlo antes de la operación vma_refcount_put(). [surenb@google.com: v3]