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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/gt: corrige un posible UAF mediante la revocación de los registros de valla. CI ha estado informando esporádicamente el siguiente problema provocado por igt@i915_selftest@live@hangcheck en ADL-P y máquinas similares. : <6> [414.049203] I915: ejecutando Intel_hangcheck_live_SelfTests/IGT_RESET_EVICT_FENCE ... <6> [414.068804] I915 0000: 00: 02.0: [DRM] GT0: GUC: CUBLICIDAD : [drm] GT0: GUC: SLPC habilitado <3> [414.070354] No se puede fijar la cerca con mosaicos en Y; err:-4 <3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active)) ... <4>[ 609.603992] ------------[ cortar aquí ]- ----------- <2>[ 609.603995] ¡ERROR del kernel en drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301! <4>[ 609.604003] código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI <4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Contaminado: GUW 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1 <4 >[ 609.604008] Nombre del hardware: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 20/01/2023 <4>[ 609.604010] Cola de trabajo: i915 __i915_gem_free_work [i915] <4 >[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915] ... <4>[ 609.604271] Seguimiento de llamadas: <4>[ 609.604273] ... <4>[ 609.604716] ct+0x2e9/ 0x550 [i915] <4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915] <4>[ 609.604977] force_unbind+0x24/0xa0 [i915] <4>[ 609.605098] x2f/0xa0 [i915] <4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915] <4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915] <4>[ 609.605440 process_scheduled_works+0x351/0x690... En el pasado, hubo fallas similares informado por CI de otras pruebas de IGT, observado en otras plataformas. Antes de confirmar 63baf4f3d587 ("drm/i915/gt: solo espere la actividad de la GPU antes de desvincular una valla GGTT"), i915_vma_revoke_fence() estaba esperando la inactividad de vma->active a través de fence_update(). Ese compromiso introdujo vma->fence->active para que fence_update() pudiera esperar selectivamente en ese en lugar de vma->active, ya que solo se necesitaba la inactividad de los registros de cerca. Pero luego, otra confirmación 0d86ee35097a ("drm/i915/gt: Hacer que la revocación de la valla sea inequívoca") reemplazó la llamada a fence_update() en i915_vma_revoke_fence() con solo fence_write(), y también agregó que GEM_BUG_ON(!i915_active_is_idle(&fence->active )) Al frente. No se proporcionó ninguna justificación sobre por qué podríamos esperar que vma->fence->active esté inactivo sin esperarlo primero. El problema puede deberse potencialmente a una carrera entre la revocación de registros de valla por un lado y la ejecución secuencial de devoluciones de llamadas de señales invocadas al completar una solicitud que las estaba usando por el otro, aún procesadas en paralelo a la revocación de esos registros de valla. Solucionelo esperando a que vma->fence->active esté inactivo en i915_vma_revoke_fence(). (cereza escogida del compromiso 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)