CVE-2024-56552

See a problem?
Please try reporting it to the source first.
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
Related
Published
2024-12-27T15:15:13Z
Modified
2025-01-14T12:18:34.856270Z
Summary
[none]
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

Debian:13 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
6.12.5-1

Affected versions

6.*

6.1.27-1
6.1.37-1
6.1.38-1
6.1.38-2~bpo11+1
6.1.38-2
6.1.38-3
6.1.38-4~bpo11+1
6.1.38-4
6.1.52-1
6.1.55-1~bpo11+1
6.1.55-1
6.1.64-1
6.1.66-1
6.1.67-1
6.1.69-1~bpo11+1
6.1.69-1
6.1.76-1~bpo11+1
6.1.76-1
6.1.82-1
6.1.85-1
6.1.90-1~bpo11+1
6.1.90-1
6.1.94-1~bpo11+1
6.1.94-1
6.1.98-1
6.1.99-1
6.1.106-1
6.1.106-2
6.1.106-3
6.1.112-1
6.1.115-1
6.1.119-1
6.1.123-1
6.1.124-1
6.3.1-1~exp1
6.3.2-1~exp1
6.3.4-1~exp1
6.3.5-1~exp1
6.3.7-1~bpo12+1
6.3.7-1
6.3.11-1
6.4~rc6-1~exp1
6.4~rc7-1~exp1
6.4.1-1~exp1
6.4.4-1~bpo12+1
6.4.4-1
6.4.4-2
6.4.4-3~bpo12+1
6.4.4-3
6.4.11-1
6.4.13-1
6.5~rc4-1~exp1
6.5~rc6-1~exp1
6.5~rc7-1~exp1
6.5.1-1~exp1
6.5.3-1~bpo12+1
6.5.3-1
6.5.6-1
6.5.8-1
6.5.10-1~bpo12+1
6.5.10-1
6.5.13-1
6.6.3-1~exp1
6.6.4-1~exp1
6.6.7-1~exp1
6.6.8-1
6.6.9-1
6.6.11-1
6.6.13-1~bpo12+1
6.6.13-1
6.6.15-1
6.6.15-2
6.7-1~exp1
6.7.1-1~exp1
6.7.4-1~exp1
6.7.7-1
6.7.9-1
6.7.9-2
6.7.12-1~bpo12+1
6.7.12-1
6.8.9-1
6.8.11-1
6.8.12-1~bpo12+1
6.8.12-1
6.9.2-1~exp1
6.9.7-1~bpo12+1
6.9.7-1
6.9.8-1
6.9.9-1
6.9.10-1~bpo12+1
6.9.10-1
6.9.11-1
6.9.12-1
6.10-1~exp1
6.10.1-1~exp1
6.10.3-1
6.10.4-1
6.10.6-1~bpo12+1
6.10.6-1
6.10.7-1
6.10.9-1
6.10.11-1~bpo12+1
6.10.11-1
6.10.12-1
6.11~rc4-1~exp1
6.11~rc5-1~exp1
6.11-1~exp1
6.11.2-1
6.11.4-1
6.11.5-1~bpo12+1
6.11.5-1
6.11.6-1
6.11.7-1
6.11.9-1
6.11.10-1~bpo12+1
6.11.10-1
6.12~rc6-1~exp1
6.12.3-1

Ecosystem specific 

{
    "urgency": "not yet assigned"
}