CVE-2024-39486

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/drm_file: corrige la carrera de recuento de pid filp->pid se supone que es un puntero recontado; sin embargo, antes de este parche, drm_file_update_pid() solo incrementa el recuento de una estructura pid después de almacenar un puntero a ella en filp->pid y eliminar dev->filelist_mutex, haciendo posible la siguiente carrera: proceso A proceso B ==== ===== ========= comenzar drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, , 1) mutex_unlock(&dev->filelist_mutex) begin drm_file_update_pid mutex_lock(&dev- >filelist_mutex) rcu_replace_pointer(filp->pid, , 1) mutex_unlock(&dev->filelist_mutex) get_pid() synchronize_rcu() put_pid() *** pid B alcanza refcount 0 y se libera aquí *** get_pid() *** UAF *** synchronize_rcu() put_pid() Hasta donde yo sé, esta carrera solo puede ocurrir con CONFIG_PREEMPT_RCU=y porque requiere que RCU detecte un estado inactivo en el código que no llame explícitamente al programador. Esta ejecucón conduce al use after free de una "estructura pid". Probablemente sea algo difícil de lograr porque el proceso A tiene que pasar por una operación synchronize_rcu() mientras que el proceso B está entre mutex_unlock() y get_pid(). Solucionelo asegurándose de que cuando se almacene en el archivo un puntero al pid de la tarea actual, se haya tomado una referencia adicional al pid. Esta solución también elimina la condición de synchronize_rcu(); Creo que la optimización es una complejidad innecesaria, ya que en ese caso normalmente habríamos abandonado la verificación sin bloqueo anterior.