CVE-2024-56552: drm/xe/guc_submit: fix race around suspend_pending
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)
Security readout for executives and security teams
Plain-English summary
A high-severity race condition affects the Linux Xe graphics driver’s GuC queue handling. Closing a queue while suspension is pending can cause incorrect deregistration, assertions, warnings, and attempted double unregister. The CVSS assessment indicates potentially serious system impact, but the supplied evidence does not demonstrate a practical compromise or remote attack path.
Executive priority
Prioritize remediation on multi-user workstations, shared compute systems, and other hosts using the affected Xe graphics path. The local-access requirement lowers urgency compared with remote vulnerabilities, but kernel-level impact and the 7.8 CVSS score justify prompt patching. Exact exposure should be confirmed with the operating-system vendor.
Technical view
The race occurs around suspend_pending when an execution queue is suspended and then closed before the asynchronous disable-scheduling response arrives. Clearing suspend_pending can make the response handler deregister a queue that is not ready for destruction, followed by duplicate unregister activity. The fix changes response ordering and makes destruction wait for pending_disable.
Likely exposure
Exposure is limited to Linux systems using the affected DRM Xe driver and GuC submission path. The source lists affected versions including 6.8, 6.12.4, and 6.13, but its version-range formatting is ambiguous. Confirm exposure against kernel or distribution guidance rather than relying solely on these labels.
Exploitation context
The CVSS vector describes a local, low-complexity attack requiring low privileges and no user interaction. This CVE is not listed as KEV, and the supplied sources provide no evidence of active exploitation or a public weaponized exploit.
Researcher notes
The issue was observed in test cases and involves asynchronous queue lifecycle handling. No CWE is supplied. The stated correction reorders disable-scheduling response processing and waits for pending_disable before marking a queue destroyed. The sources do not establish reliable exploitation, root escalation, or the precise vulnerable release boundaries.
Mitigation direction
Update to a vendor-supported kernel containing the referenced stable fix.
Confirm the distribution’s security advisory or changelog identifies CVE-2024-56552 as resolved.
Prioritize systems using the Xe DRM driver and GuC submission.
Restrict unnecessary local account access until affected systems are updated.
Validation and detection
Inventory kernel versions on systems using Intel graphics and the Xe driver.
Verify the installed kernel contains the referenced stable fix or vendor backport.
Review kernel logs for xe_guc_submit assertions, unexpected engine states, or duplicate unregister symptoms.
Retest affected GPU workloads after updating and confirm the warnings no longer occur.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-56552 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
3Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.