{
   cveTags: [],
   descriptions: [
      {
         lang: "en",
         value: "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/guc_submit: fix race around suspend_pending\n\nCurrently in some testcases we can trigger:\n\nxe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed!\n....\nWARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe]\nxe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57\n\nLooking at a snippet of corresponding ftrace for this GuC id we can see:\n\n162.673311: xe_sched_msg_add:     dev=0000:03:00.0, gt=1 guc_id=57, opcode=3\n162.673317: xe_sched_msg_recv:    dev=0000:03:00.0, gt=1 guc_id=57, opcode=3\n162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0\n162.674089: xe_exec_queue_kill:   dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0\n162.674108: xe_exec_queue_close:  dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0\n162.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\n162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0\n\nIt looks like we try to suspend the queue (opcode=3), setting\nsuspend_pending and triggering a disable_scheduling. The user then\ncloses the queue. However the close will also forcefully signal the\nsuspend fence after killing the queue, later when the G2H response for\ndisable_scheduling comes back we have now cleared suspend_pending when\nsignalling the suspend fence, so the disable_scheduling now incorrectly\ntries to also deregister the queue. This leads to warnings since the queue\nhas yet to even be marked for destruction. We also seem to trigger\nerrors later with trying to double unregister the same queue.\n\nTo fix this tweak the ordering when handling the response to ensure we\ndon't race with a disable_scheduling that didn't actually intend to\nperform an unregister.  The destruction path should now also correctly\nwait for any pending_disable before marking as destroyed.\n\n(cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)",
      },
      {
         lang: "es",
         value: "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)",
      },
   ],
   id: "CVE-2024-56552",
   lastModified: "2024-12-27T15:15:13.970",
   metrics: {},
   published: "2024-12-27T15:15:13.970",
   references: [
      {
         source: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
         url: "https://git.kernel.org/stable/c/5ddcb50b700221fa7d7be2adcb3d7d7afe8633dd",
      },
      {
         source: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
         url: "https://git.kernel.org/stable/c/87651f31ae4e6e6e7e6c7270b9b469405e747407",
      },
   ],
   sourceIdentifier: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   vulnStatus: "Awaiting Analysis",
}