CVE-2024-56552

Source
https://nvd.nist.gov/vuln/detail/CVE-2024-56552
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-56552.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2024-56552
Downstream
Related
Published
2024-12-27T14:22:54Z
Modified
2025-10-22T06:24:21.537988Z
Summary
drm/xe/guc_submit: fix race around suspend_pending
Details

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 exec_queue_destroyed(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, guc_state=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 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 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)

References

Affected packages

Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Affected ranges

Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
dd08ebf6c3525a7ea2186e636df064ea47281987
Fixed
5ddcb50b700221fa7d7be2adcb3d7d7afe8633dd
Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
dd08ebf6c3525a7ea2186e636df064ea47281987
Fixed
87651f31ae4e6e6e7e6c7270b9b469405e747407

Affected versions

v6.*

v6.10
v6.10-rc1
v6.10-rc2
v6.10-rc3
v6.10-rc4
v6.10-rc5
v6.10-rc6
v6.10-rc7
v6.11
v6.11-rc1
v6.11-rc2
v6.11-rc3
v6.11-rc4
v6.11-rc5
v6.11-rc6
v6.11-rc7
v6.12
v6.12-rc1
v6.12-rc2
v6.12-rc3
v6.12-rc4
v6.12-rc5
v6.12-rc6
v6.12-rc7
v6.12.1
v6.12.2
v6.12.3
v6.7
v6.7-rc4
v6.7-rc5
v6.7-rc6
v6.7-rc7
v6.7-rc8
v6.8
v6.8-rc1
v6.8-rc2
v6.8-rc3
v6.8-rc4
v6.8-rc5
v6.8-rc6
v6.8-rc7
v6.9
v6.9-rc1
v6.9-rc2
v6.9-rc3
v6.9-rc4
v6.9-rc5
v6.9-rc6
v6.9-rc7

Linux / Kernel

Package

Name
Kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
6.8.0
Fixed
6.12.4