CVE-2024-56552: Vulnerability in Linux Linux
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)
AI Analysis
Technical Summary
CVE-2024-56552 is a vulnerability identified in the Linux kernel, specifically within the Direct Rendering Manager (DRM) subsystem for Intel Xe graphics (xe driver). The issue arises from a race condition around the handling of the suspend_pending flag during the suspend and deregistration process of execution queues (exec_queues) managed by the GuC firmware scheduler. The vulnerability manifests when the kernel attempts to suspend an execution queue by setting suspend_pending and disabling scheduling, followed by closing the queue. The close operation forcefully signals the suspend fence after killing the queue, but when the disable_scheduling response returns, suspend_pending has been cleared prematurely. This causes the disable_scheduling handler to incorrectly attempt to deregister the queue twice, leading to warnings and errors such as assertion failures and unexpected engine states. The root cause is a race condition in the ordering of operations between suspending, closing, and deregistering the execution queue, which can cause inconsistent states and potential kernel instability or crashes. The fix involves adjusting the handling order of the disable_scheduling response to avoid racing with unregister operations and ensuring the destruction path waits for any pending disable operations before marking the queue as destroyed. This vulnerability affects Linux kernel versions including the commit dd08ebf6c3525a7ea2186e636df064ea47281987 and likely other versions containing the affected drm/xe/xe_guc_submit.c code. There are no known exploits in the wild at this time, and no CVSS score has been assigned yet.
Potential Impact
For European organizations, the impact of CVE-2024-56552 primarily concerns systems running Linux kernels with Intel Xe graphics hardware that utilize the GuC firmware scheduler, which is common in modern Intel integrated GPUs. The vulnerability could lead to kernel warnings, assertion failures, and potentially kernel panics or system instability due to race conditions in GPU command queue management. This can cause denial of service (DoS) conditions on affected systems, disrupting critical workloads that rely on GPU acceleration, such as graphical user interfaces, compute tasks, or virtualization environments. While there is no indication that this vulnerability leads to privilege escalation or arbitrary code execution, the instability and potential crashes can impact availability and operational continuity. Organizations in sectors relying heavily on Linux-based infrastructure with Intel GPUs—such as research institutions, media production, and cloud service providers—may experience service interruptions. Additionally, embedded systems or edge devices using Linux with Intel GPUs could be affected, impacting IoT or industrial control systems. The lack of known exploits reduces immediate risk, but the vulnerability should be addressed promptly to prevent potential exploitation or accidental system failures.
Mitigation Recommendations
To mitigate CVE-2024-56552, European organizations should: 1) Apply the official Linux kernel patches that fix the race condition in the drm/xe/xe_guc_submit.c driver as soon as they become available from trusted Linux distributions or kernel maintainers. 2) Monitor kernel updates from their Linux vendors and prioritize updates for systems with Intel Xe graphics hardware. 3) For critical production environments, consider temporarily disabling GPU acceleration or the GuC scheduler if feasible, to avoid triggering the race condition until patches are applied. 4) Implement robust system monitoring and logging to detect kernel warnings or GPU driver errors that may indicate attempts to exploit or trigger the vulnerability. 5) Conduct thorough testing of updated kernels in staging environments to ensure stability before wide deployment. 6) Engage with hardware and software vendors to confirm compatibility and support for patched kernels. 7) Educate system administrators and security teams about the symptoms of this vulnerability to enable rapid incident response. These steps go beyond generic advice by focusing on hardware-specific mitigation, patch management prioritization, and operational monitoring tailored to the Intel Xe GPU context.
Affected Countries
Germany, France, United Kingdom, Netherlands, Sweden, Finland, Poland, Italy, Spain
CVE-2024-56552: Vulnerability in Linux Linux
Description
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)
AI-Powered Analysis
Technical Analysis
CVE-2024-56552 is a vulnerability identified in the Linux kernel, specifically within the Direct Rendering Manager (DRM) subsystem for Intel Xe graphics (xe driver). The issue arises from a race condition around the handling of the suspend_pending flag during the suspend and deregistration process of execution queues (exec_queues) managed by the GuC firmware scheduler. The vulnerability manifests when the kernel attempts to suspend an execution queue by setting suspend_pending and disabling scheduling, followed by closing the queue. The close operation forcefully signals the suspend fence after killing the queue, but when the disable_scheduling response returns, suspend_pending has been cleared prematurely. This causes the disable_scheduling handler to incorrectly attempt to deregister the queue twice, leading to warnings and errors such as assertion failures and unexpected engine states. The root cause is a race condition in the ordering of operations between suspending, closing, and deregistering the execution queue, which can cause inconsistent states and potential kernel instability or crashes. The fix involves adjusting the handling order of the disable_scheduling response to avoid racing with unregister operations and ensuring the destruction path waits for any pending disable operations before marking the queue as destroyed. This vulnerability affects Linux kernel versions including the commit dd08ebf6c3525a7ea2186e636df064ea47281987 and likely other versions containing the affected drm/xe/xe_guc_submit.c code. There are no known exploits in the wild at this time, and no CVSS score has been assigned yet.
Potential Impact
For European organizations, the impact of CVE-2024-56552 primarily concerns systems running Linux kernels with Intel Xe graphics hardware that utilize the GuC firmware scheduler, which is common in modern Intel integrated GPUs. The vulnerability could lead to kernel warnings, assertion failures, and potentially kernel panics or system instability due to race conditions in GPU command queue management. This can cause denial of service (DoS) conditions on affected systems, disrupting critical workloads that rely on GPU acceleration, such as graphical user interfaces, compute tasks, or virtualization environments. While there is no indication that this vulnerability leads to privilege escalation or arbitrary code execution, the instability and potential crashes can impact availability and operational continuity. Organizations in sectors relying heavily on Linux-based infrastructure with Intel GPUs—such as research institutions, media production, and cloud service providers—may experience service interruptions. Additionally, embedded systems or edge devices using Linux with Intel GPUs could be affected, impacting IoT or industrial control systems. The lack of known exploits reduces immediate risk, but the vulnerability should be addressed promptly to prevent potential exploitation or accidental system failures.
Mitigation Recommendations
To mitigate CVE-2024-56552, European organizations should: 1) Apply the official Linux kernel patches that fix the race condition in the drm/xe/xe_guc_submit.c driver as soon as they become available from trusted Linux distributions or kernel maintainers. 2) Monitor kernel updates from their Linux vendors and prioritize updates for systems with Intel Xe graphics hardware. 3) For critical production environments, consider temporarily disabling GPU acceleration or the GuC scheduler if feasible, to avoid triggering the race condition until patches are applied. 4) Implement robust system monitoring and logging to detect kernel warnings or GPU driver errors that may indicate attempts to exploit or trigger the vulnerability. 5) Conduct thorough testing of updated kernels in staging environments to ensure stability before wide deployment. 6) Engage with hardware and software vendors to confirm compatibility and support for patched kernels. 7) Educate system administrators and security teams about the symptoms of this vulnerability to enable rapid incident response. These steps go beyond generic advice by focusing on hardware-specific mitigation, patch management prioritization, and operational monitoring tailored to the Intel Xe GPU context.
Affected Countries
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- Linux
- Date Reserved
- 2024-12-27T14:03:05.990Z
- Cisa Enriched
- false
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d9823c4522896dcbdf1eb
Added to database: 5/21/2025, 9:08:51 AM
Last enriched: 6/28/2025, 11:41:16 AM
Last updated: 7/29/2025, 8:47:42 AM
Views: 10
Related Threats
CVE-2025-9010: SQL Injection in itsourcecode Online Tour and Travel Management System
MediumCVE-2025-9009: SQL Injection in itsourcecode Online Tour and Travel Management System
MediumCVE-2025-31961: CWE-1220 Insufficient Granularity of Access Control in HCL Software Connections
LowCVE-2025-9008: SQL Injection in itsourcecode Online Tour and Travel Management System
MediumCVE-2025-9007: Buffer Overflow in Tenda CH22
HighActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
External Links
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.