CVE-2024-56552 (GCVE-0-2024-56552)
Vulnerability from cvelistv5 – Published: 2024-12-27 14:22 – Updated: 2026-08-05 11:45
VLAI
EPSS
VEX
Title
drm/xe/guc_submit: fix race around suspend_pending
Summary
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/guc_submit: fix race around suspend_pending
Currently in some testcases we can trigger:
xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed!
....
WARNING: CPU: 18 PID: 2640 at 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: Unexpected engine state 0x00a1, guc_id=57
Looking at a snippet of corresponding ftrace for this GuC id we can see:
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, opcode=3
162.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
162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=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
It looks like we try to suspend the queue (opcode=3), setting
suspend_pending and triggering a disable_scheduling. The user then
closes the queue. However the close will also forcefully signal the
suspend fence after killing the queue, later when the G2H response for
disable_scheduling comes back we have now cleared suspend_pending when
signalling the suspend fence, so the disable_scheduling now incorrectly
tries to also deregister the queue. This leads to warnings since the queue
has yet to even be marked for destruction. We also seem to trigger
errors later with trying to double unregister the same queue.
To fix this tweak the ordering when handling the response to ensure we
don't race with a disable_scheduling that didn't actually intend to
perform an unregister. The destruction path should now also correctly
wait for any pending_disable before marking as destroyed.
(cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)
Severity
7.8 (High)
Assigner
References
Impacted products
2 products
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
dd08ebf6c3525a7ea2186e636df064ea47281987 , < 5ddcb50b700221fa7d7be2adcb3d7d7afe8633dd
(git)
Affected: dd08ebf6c3525a7ea2186e636df064ea47281987 , < 87651f31ae4e6e6e7e6c7270b9b469405e747407 (git) |
guessed | |
| Linux | Linux |
Affected:
6.8
Unaffected: 0 , < 6.8 (semver) Unaffected: 6.12.4 , ≤ 6.12.* (semver) Unaffected: 6.13 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/gpu/drm/xe/xe_guc_submit.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "5ddcb50b700221fa7d7be2adcb3d7d7afe8633dd",
"status": "affected",
"version": "dd08ebf6c3525a7ea2186e636df064ea47281987",
"versionType": "git"
},
{
"lessThan": "87651f31ae4e6e6e7e6c7270b9b469405e747407",
"status": "affected",
"version": "dd08ebf6c3525a7ea2186e636df064ea47281987",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/gpu/drm/xe/xe_guc_submit.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.8"
},
{
"lessThan": "6.8",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.13",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.4",
"versionStartIncluding": "6.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.13",
"versionStartIncluding": "6.8",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"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\u0027t race with a disable_scheduling that didn\u0027t 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)"
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The race is driven entirely through Intel Xe DRM ioctls (`XE_VM_BIND`/`XE_EXEC` triggering preempt-fence suspend, and `XE_EXEC_QUEUE_DESTROY`) on the local `/dev/dri/renderD*` node. No network or adjacent-network path reaches `xe_guc_submit.c`.\nAC:L - The attacker owns both sides of the race \u2014 it issues the operation that sets `suspend_pending` and fires `disable_scheduling()`, then closes the queue from another thread inside the GuC round-trip window, which the reported ftrace shows is ~1.2 ms wide. It reproduces in ordinary IGT test runs and can be looped across many exec queues concurrently until it lands.\nPR:L - Every ioctl on the path (`XE_VM_CREATE`, `XE_EXEC_QUEUE_CREATE`, `XE_VM_BIND`, `XE_EXEC`, `XE_EXEC_QUEUE_DESTROY`) is flagged `DRM_RENDER_ALLOW`, so any unprivileged process holding the render node \u2014 every GPU-using app on a desktop, Android, or ChromeOS system, including sandboxed browser GPU processes and containers with GPU passthrough \u2014 can reach it. No capability or DRM_MASTER is required.\nUI:N - A single unprivileged process performs the suspend-inducing operation and the queue destroy from its own threads. No victim action or cooperating user is involved.\nS:U - The corrupted state, freed objects, and resulting GT reset are all within the kernel\u0027s own security authority on the host. No VM, IOMMU, or hypervisor boundary is crossed.\nC:H - The out-of-protocol deregister lets `handle_deregister_done()` run against a queue whose lifetime the driver still owns, producing double `kfree(ge)`/`xe_exec_queue_fini(q)` and \u2014 once `release_guc_id()` recycles the id \u2014 a stale `DEREGISTER_DONE` landing on a different live queue. That use-after-free over attacker-shaped heap objects yields a read primitive into freed kernel memory.\nI:H - The same double-deregister drives `__guc_exec_queue_fini()` twice, re-running `INIT_WORK` on an already-queued work item and double-freeing `xe_guc_exec_queue`/`xe_exec_queue`, giving a write primitive into reclaimed slab memory that is exploitable for control-flow hijack via heap spraying.\nA:H - Confirmed WARN/assert splat plus permanent driver-versus-GuC state desync: the rejected `DEREGISTER_DONE` (`-EPROTO`) leaks the exec queue, its guc_id and its G2H credit forever, the follow-up `DISABLE` to an already-deregistered context times out into `xe_gt_reset_async()` killing all GPU contexts on the tile, and `show_run_ticks()`\u0027s untimed `wait_var_event()` on `pending_removal` hangs fdinfo readers in unkillable uninterruptible sleep."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:45:00.626Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/5ddcb50b700221fa7d7be2adcb3d7d7afe8633dd"
},
{
"url": "https://git.kernel.org/stable/c/87651f31ae4e6e6e7e6c7270b9b469405e747407"
}
],
"title": "drm/xe/guc_submit: fix race around suspend_pending",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-56552",
"datePublished": "2024-12-27T14:22:54.140Z",
"dateReserved": "2024-12-27T14:03:05.990Z",
"dateUpdated": "2026-08-05T11:45:00.626Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2024-56552",
"date": "2026-09-30",
"epss": "0.00146",
"percentile": "0.03271"
},
"fkie_nvd": {
"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\u0027t race with a disable_scheduling that didn\u0027t 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\u00f3n alrededor de suspend_pending Actualmente en algunos casos de prueba podemos activar: xe 0000:03:00.0: [drm] \u00a1La afirmaci\u00f3n `exec_queue_destroyed(q)` fall\u00f3! .... 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\u00f3digo de operaci\u00f3n=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\u00e9n se\u00f1alar\u00e1 con fuerza la valla de suspensi\u00f3n despu\u00e9s de matar la cola, m\u00e1s tarde, cuando la respuesta G2H para deshabilitar_programaci\u00f3n regrese, ahora hemos borrado suspend_pending al se\u00f1alar la valla de suspensi\u00f3n, por lo que deshabilitar_programaci\u00f3n ahora intenta incorrectamente tambi\u00e9n anular el registro de la cola. Esto genera advertencias ya que la cola a\u00fan no se ha marcado para su destrucci\u00f3n. Tambi\u00e9n parece que desencadenamos errores m\u00e1s 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\u00f3n que en realidad no ten\u00eda la intenci\u00f3n de realizar una anulaci\u00f3n del registro. La ruta de destrucci\u00f3n ahora tambi\u00e9n deber\u00eda 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",
"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"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/gpu/drm/xe/xe_guc_submit.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "5ddcb50b700221fa7d7be2adcb3d7d7afe8633dd",
"status": "affected",
"version": "dd08ebf6c3525a7ea2186e636df064ea47281987",
"versionType": "git"
},
{
"lessThan": "87651f31ae4e6e6e7e6c7270b9b469405e747407",
"status": "affected",
"version": "dd08ebf6c3525a7ea2186e636df064ea47281987",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/gpu/drm/xe/xe_guc_submit.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.8"
},
{
"lessThan": "6.8",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.13",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "21856C26-95A5-464A-B4C0-CFBF485C6080",
"versionEndExcluding": "6.12.4",
"versionStartIncluding": "6.8",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"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\u0027t race with a disable_scheduling that didn\u0027t 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\u00f3n alrededor de suspend_pending Actualmente en algunos casos de prueba podemos activar: xe 0000:03:00.0: [drm] \u00a1La afirmaci\u00f3n `exec_queue_destroyed(q)` fall\u00f3! .... 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\u00f3digo de operaci\u00f3n=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\u00e9n se\u00f1alar\u00e1 con fuerza la valla de suspensi\u00f3n despu\u00e9s de matar la cola, m\u00e1s tarde, cuando la respuesta G2H para deshabilitar_programaci\u00f3n regrese, ahora hemos borrado suspend_pending al se\u00f1alar la valla de suspensi\u00f3n, por lo que deshabilitar_programaci\u00f3n ahora intenta incorrectamente tambi\u00e9n anular el registro de la cola. Esto genera advertencias ya que la cola a\u00fan no se ha marcado para su destrucci\u00f3n. Tambi\u00e9n parece que desencadenamos errores m\u00e1s 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\u00f3n que en realidad no ten\u00eda la intenci\u00f3n de realizar una anulaci\u00f3n del registro. La ruta de destrucci\u00f3n ahora tambi\u00e9n deber\u00eda esperar correctamente cualquier pendiente_deshabilitar antes de marcar como destruida. (seleccionado de el commit f161809b362f027b6d72bd998e47f8f0bad60a2e)"
}
],
"id": "CVE-2024-56552",
"lastModified": "2026-08-04T11:22:10.013",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"cvssData": {
"attackComplexity": "HIGH",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 4.7,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.0,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2024-12-27T15:15:13.970",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5ddcb50b700221fa7d7be2adcb3d7d7afe8633dd"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/87651f31ae4e6e6e7e6c7270b9b469405e747407"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-362"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "None",
"current_release_date": "2025-11-25T08:45:19+00:00",
"cve": "CVE-2024-56552",
"id": "CVE-2024-56552",
"initial_release_date": "2024-12-27T00:00:00+00:00",
"product_status:known_not_affected": "198",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: drm/xe/guc_submit: fix race around suspend_pending",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-56552.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "moderate",
"current_release_date": "2026-09-01T13:56:54Z",
"cve": "CVE-2024-56552",
"id": "CVE-2024-56552",
"initial_release_date": "2024-12-28T03:49:00Z",
"product_status:known_not_affected": "547",
"product_status:recommended": "125",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2024-56552",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2024-56552.json",
"version": "26"
}
}
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.
Loading…