Vulnerabilidad en kernel de Linux (CVE-2024-26939)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/i915/vma: Corrección de UAF al destruir contra ejecución de retirada. Las herramientas de depuración de objetos informaban esporádicamente intentos ilegales de liberar un objeto i915 VMA aún activo al estacionar un GT que se creía que estaba inactivo. [161.359441] ODEBUG: objeto activo libre (estado activo 0): ffff88811643b958 tipo de objeto: i915_active sugerencia: __i915_vma_active+0x0/0x50 [i915] [161.360082] ADVERTENCIA: CPU: 5 PID: 276 en lib/debugobjects.c:514 _imprimir_objeto+ 0x80/0xb0 ... [161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 No contaminado 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1 [161.360314] Nombre de hardware: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 21/04/2022 [161.360322] Cola de trabajo: i915 desordenado __intel_wakeref_put_work [i915] [161.360592] RIP 0010:debug_print_object+0x 80/0xb0... [161.361347] debug_object_free +0xeb/0x110 [161.361362] i915_active_fini+0x14/0x130 [i915] [161.361866] referencias de versión+0xfe/0x1f0 [i915] [161.362543] i915_vma_parked+0x1db/0x380 [i915] .363129] __gt_park+0x121/0x230 [i915] [161.363515 ] ____intel_wakeref_put_last+0x1f/0x70 [i915] Se ha rastreado que eso sucede cuando otro subproceso desactiva el VMA dentro del asistente __active_retire(), después de que el contador activo del VMA ya se haya reducido a 0, pero antes de que se desactive la desactivación del objeto del VMA. reportado a la herramienta de depuración de objetos. Podríamos evitar esa ejecución serializando i915_active_fini() con __active_retire() a través de ref->tree_lock, pero eso no impediría que se use VMA, por ejemplo, desde __i915_vma_retire() llamado al final de __active_retire(), después de ese VMA ya ha sido liberado por un i915_vma_destroy() concurrente al regresar de i915_active_fini(). Entonces, deberíamos solucionar el problema a nivel de VMA, no en i915_active. Dado que __i915_vma_parked() se llama desde __gt_park() en la última colocación del wakeref del GT, el problema podría solucionarse manteniendo el wakeref del GT el tiempo suficiente para que __active_retire() se complete antes de que se libere el wakeref y se estacione el GT. Creo que el problema fue introducido por el commit d93939730347 ("drm/i915: Eliminar el recuento de vma") que movió una llamada a i915_active_fini() desde un i915_vma_release() eliminado, llamado en la última colocación del kref de VMA eliminado, a i915_vma_parked() ruta de procesamiento llamada en la última colocación de un wakeref GT. Sin embargo, su visibilidad para la herramienta de depuración de objetos fue suprimida por un error en i915_active que se solucionó dos semanas después con el commit e92eb246feb9 ("drm/i915/active: Reparar la activación del objeto de depuración que falta"). Un VMA asociado con una solicitud no adquiere un wakeref GT por sí solo. En cambio, depende de un wakeref mantenido directamente por el intel_context activo de la solicitud para un GT asociado con su VM, e indirectamente del wakeref del motor de ese intel_context si el motor pertenece al mismo GT que la VM del VMA. Esos wakerefs se liberan de forma asincrónica con la desactivación de VMA. Solucione el problema obteniendo un wakeref para el GT del VMA al activarlo y colocando ese wakeref solo después de que se desactive el VMA. Sin embargo, excluya el GTT global de esa ruta de procesamiento; de lo contrario, la GPU nunca quedará inactiva. Dado que se puede llamar a __i915_vma_retire() desde contextos atómicos, utilice la variante asíncrona de wakeref put. Además, para evitar la dependencia del bloqueo circular, tenga cuidado de adquirir el wakeref antes del mutex de VM cuando ambos sean necesarios. v7: agregue comentarios en línea con justificaciones para: - usar variantes sin seguimiento de intel_gt_pm_get/put() (Nirmoy), - usar la variante asíncrona de _put(), - no obtener el wakeref en caso de un GTT global, - obtener siempre el primer wakeref fuera de vm->mutex. ---truncado---