CVE-2025-40166: drm/xe/guc: Check GuC running state before deregistering exec queue
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/guc: Check GuC running state before deregistering exec queue
In normal operation, a registered exec queue is disabled and
deregistered through the GuC, and freed only after the GuC confirms
completion. However, if the driver is forced to unbind while the exec
queue is still running, the user may call exec_destroy() after the GuC
has already been stopped and CT communication disabled.
In this case, the driver cannot receive a response from the GuC,
preventing proper cleanup of exec queue resources. Fix this by directly
releasing the resources when GuC is not running.
Here is the failure dmesg log:
"
[ 468.089581] ---[ end trace 0000000000000000 ]---
[ 468.089608] pci 0000:03:00.0: [drm] *ERROR* GT0: GUC ID manager unclean (1/65535)
[ 468.090558] pci 0000:03:00.0: [drm] GT0: total 65535
[ 468.090562] pci 0000:03:00.0: [drm] GT0: used 1
[ 468.090564] pci 0000:03:00.0: [drm] GT0: range 1..1 (1)
[ 468.092716] ------------[ cut here ]------------
[ 468.092719] WARNING: CPU: 14 PID: 4775 at drivers/gpu/drm/xe/xe_ttm_vram_mgr.c:298 ttm_vram_mgr_fini+0xf8/0x130 [xe]
"
v2: use xe_uc_fw_is_running() instead of xe_guc_ct_enabled().
As CT may go down and come back during VF migration.
(cherry picked from commit 9b42321a02c50a12b2beb6ae9469606257fbecea)
Security readout for executives and security teams
Plain-English summary
A local user may trigger faulty GPU resource cleanup when the Linux drm/xe driver is unbound while work remains active. The driver can wait for a stopped GuC component and leave resources uncleared, producing kernel warnings. The supplied CVSS rating is 7.8 (high), although the description does not independently demonstrate confidentiality or integrity impact.
Executive priority
Treat as a high-priority maintenance update for affected GPU hosts, especially multi-user systems where untrusted users receive local access. It is not supported as an internet-scale emergency because the evidence shows a local, state-dependent condition and no known active exploitation. Escalate if vendor advisories identify broader consequences.
Technical view
The drm/xe driver normally deregisters an execution queue through GuC and waits for confirmation before freeing it. During forced unbind, GuC and its communication channel may already be stopped when exec_destroy() runs, preventing confirmation and cleanup. The fix checks whether GuC firmware is running and releases resources directly when it is not.
Likely exposure
Exposure is limited to Linux systems using the drm/xe driver and affected kernels. Triggering requires local low-privilege access and a specific lifecycle condition involving an active execution queue, forced driver unbind, stopped GuC, and subsequent queue destruction. The bundle's affected-version data is not sufficiently normalized to establish reliable version boundaries.
Exploitation context
The CVSS vector indicates local access, low complexity, low privileges, and no user interaction. The source bundle does not report CISA KEV listing, active exploitation, public exploit availability, or remote reachability. Reported evidence consists of resource-cleanup failure, an unclean GuC ID manager, and a kernel warning.
Researcher notes
The reported defect is a GuC state-check and cleanup-path error in drm/xe. The description supports a resource leak and warning during teardown but does not explain how the CVSS confidentiality, integrity, and availability impacts become high. No CWE is supplied. Exact affected ranges and security consequences therefore require confirmation from kernel or distribution maintainers.
Mitigation direction
Install a vendor-supported kernel containing the cited stable fix.
Confirm distribution guidance because the supplied affected-version boundaries are ambiguous.
Restrict unnecessary local access on exposed multi-user GPU systems until updated.
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-2025-40166 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
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
4Source 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.