CVE-2024-56552: drm/xe/guc_submit: fix race around suspend_pending
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/gucsubmit: fix race around suspendpending
Currently in some testcases we can trigger:
xe 0000:03:00.0: [drm] Assertion execqueuedestroyed(q) failed! .... WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xegucsubmit.c:1826 xegucscheddonehandler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] ERROR GT1: DEREGISTERDONE: Unexpected engine state 0x00a1, gucid=57
Looking at a snippet of corresponding ftrace for this GuC id we can see:
162.673311: xeschedmsgadd: dev=0000:03:00.0, gt=1 gucid=57, opcode=3 162.673317: xeschedmsgrecv: dev=0000:03:00.0, gt=1 gucid=57, opcode=3 162.673319: xeexecqueueschedulingdisable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, gucid=57, gucstate=0x29, flags=0x0 162.674089: xeexecqueuekill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, gucid=57, gucstate=0x29, flags=0x0 162.674108: xeexecqueueclose: dev=0000:03:00.0, 1:0x2, gt=1, width=1, gucid=57, gucstate=0xa9, flags=0x0 162.674488: xeexecqueueschedulingdone: dev=0000:03:00.0, 1:0x2, gt=1, width=1, gucid=57, gucstate=0xa9, flags=0x0 162.678452: xeexecqueuederegister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, gucid=57, gucstate=0xa1, flags=0x0
It looks like we try to suspend the queue (opcode=3), setting suspendpending and triggering a disablescheduling. 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 disablescheduling comes back we have now cleared suspendpending when signalling the suspend fence, so the disablescheduling 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 disablescheduling that didn't actually intend to perform an unregister. The destruction path should now also correctly wait for any pendingdisable before marking as destroyed.
(cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)
Other sources
This CVE was automatically created from a reference found in an email or other text. If you are reading this, then this CVE entry is probably erroneous, since this text should be replaced by the official CVE description automatically.
— Launchpad
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 5.10.223-1Fixed in 5.10.234-1Fixed in 6.1.129-1Fixed in 6.1.135-1Fixed in 6.12.27-1
Event History
Frequently Asked Questions
What is the severity of CVE-2024-56552?
CVE-2024-56552 has a medium severity rating due to its impact on the Linux kernel's ability to handle GPU operations properly.
How do I fix CVE-2024-56552?
To fix CVE-2024-56552, update the Linux kernel to the latest version where this vulnerability has been patched.
What products are affected by CVE-2024-56552?
CVE-2024-56552 affects the Linux Kernel, specifically versions that include the mentioned drm/xe/guc_submit functionality.
What are the potential consequences of CVE-2024-56552?
The potential consequences of CVE-2024-56552 include instability in GPU functions and possible system crashes during specific operations.
Is CVE-2024-56552 being actively exploited?
There is currently no public indication that CVE-2024-56552 is being actively exploited in the wild.