LiveActive security incident?Get immediate response
CVE Record

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)

HighCVSS 7.8Not KEV-listedUpdated
Glexia's TakeAutomated analysishigh

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.
Prepared
Confidence
medium
Sources
4

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.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
High
CVSS
7.8 (3.1)
Known Exploited
No
Published

Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Official CVE source material

CNA and ADP enrichment extracted from CVE v5

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.

ScoreVersionSeverityVectorExploitImpactSource
7.8CVSS 3.1HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H1.85.9Linux

Vulnerability scoring details

Base CVSS 3.1 score

7.8High
CVSS 3.1 vector shape for CVE-2024-56552Attack VectorAttack ComplexityPrivileges RequiredUser InteractionScopeConfidentiality ImpactIntegrity ImpactAvailability Impact

Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Attack Vector
NetworkAdjacentLocalPhysical
Attack Complexity
LowHigh
Privileges Required
NoneLowHigh
User Interaction
NoneRequired
Scope
ChangedUnchanged
Confidentiality Impact
HighLowNone
Integrity Impact
HighLowNone
Availability Impact
HighLowNone

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinuxdd08ebf6c3525a7ea2186e636df064ea47281987, dd08ebf6c3525a7ea2186e636df064ea47281987unaffected
LinuxLinux6.8, 0, 6.12.4, 6.13affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.