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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/guc_submit: corrige la ejecución alrededor de suspend_pending Actualmente en algunos casos de prueba podemos activar: xe 0000:03:00.0: [drm] ¡La afirmación `exec_queue_destroyed(q)` falló! .... ADVERTENCIA: CPU: 18 PID: 2640 en drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Estado de motor inesperado 0x00a1, guc_id=57 Si observamos un fragmento de ftrace correspondiente a este id de GuC, podemos ver: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, código de operación=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, ancho=1, guc_id=57, guc_state=0x29, indicadores=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, ancho=1, guc_id=57, guc_state=0x29, indicadores=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 Parece que intentamos suspender la cola (opcode=3), configurando suspend_pending y activando un disable_scheduling. Luego, el usuario cierra la cola. Sin embargo, el cierre también señalará con fuerza la valla de suspensión después de matar la cola, más tarde, cuando la respuesta G2H para deshabilitar_programación regrese, ahora hemos borrado suspend_pending al señalar la valla de suspensión, por lo que deshabilitar_programación ahora intenta incorrectamente también anular el registro de la cola. Esto genera advertencias ya que la cola aún no se ha marcado para su destrucción. También parece que desencadenamos errores más tarde al intentar anular el registro dos veces de la misma cola. Para solucionar esto, modifique el orden al gestionar la respuesta para garantizar que no compitamos con un deshabilitar_programación que en realidad no tenía la intención de realizar una anulación del registro. La ruta de destrucción ahora también debería esperar correctamente cualquier pendiente_deshabilitar antes de marcar como destruida. (seleccionado de el commit f161809b362f027b6d72bd998e47f8f0bad60a2e)