CVE-2025-38511: drm/xe/pf: Clear all LMTT pages on alloc
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/pf: Clear all LMTT pages on alloc
Our LMEM buffer objects are not cleared by default on alloc
and during VF provisioning we only setup LMTT PTEs for the
actually provisioned LMEM range. But beyond that valid range
we might leave some stale data that could either point to some
other VFs allocations or even to the PF pages.
Explicitly clear all new LMTT page to avoid the risk that a
malicious VF would try to exploit that gap.
While around add asserts to catch any undesired PTE overwrites
and low-level debug traces to track LMTT PT life-cycle.
(cherry picked from commit 3fae6918a3e27cce20ded2551f863fb05d4bef8d)
Security readout for executives and security teams
Plain-English summary
A Linux Intel Xe GPU virtualization flaw could let a malicious virtual function access stale memory mappings left during provisioning. Those mappings might reference another virtual function’s allocations or privileged physical-function pages, creating confidentiality, integrity, and availability risk across isolation boundaries.
Executive priority
Treat as a high-priority isolation issue for multi-tenant or mixed-trust GPU virtualization hosts. Patch those systems promptly after compatibility testing. Systems without Xe PF/VF virtualization are unlikely to expose the described path, but teams should verify configuration rather than relying only on kernel version.
Technical view
New LMTT pages backed by local GPU memory were not cleared on allocation. Provisioning populated entries only for the assigned LMEM range, potentially leaving valid-looking stale entries beyond it. The kernel fix clears every new LMTT page and adds assertions and lifecycle tracing. CVSS 3.1 is 8.8: local, low-complexity, low-privilege, no user interaction, changed scope.
Likely exposure
Exposure appears limited to systems using the Linux drm/xe driver’s PF/VF GPU virtualization and LMEM provisioning. A potentially malicious or compromised VF is required. The supplied affected-version data includes Linux 6.8, 6.12.39, 6.15.7, and 6.16, but does not clearly express version-range or fixed-version boundaries.
Exploitation context
The source describes a malicious VF attempting to exploit stale mappings, but provides no evidence of exploitation in the wild. The CVE is not listed as KEV in the supplied bundle. Exploitation requires local low-privileged VF access; it is not described as remotely exploitable.
Researcher notes
The security boundary is VF-to-VF or VF-to-PF through stale LMTT PTE contents outside the provisioned LMEM range. The fix zeroes all newly allocated LMTT pages and adds overwrite assertions and debug traces. No CWE is supplied. Exact affected and fixed release boundaries cannot be confidently reconstructed from the flattened version list alone.
Mitigation direction
Update to a vendor-supported kernel containing the referenced stable fix.
Prioritize hosts providing Xe GPU virtual functions to less-trusted workloads or tenants.
If immediate updating is impossible, restrict untrusted access to affected GPU virtual functions.
Check Linux distribution and hardware-vendor advisories for exact fixed package versions.
Validation and detection
Inventory kernels, Intel Xe GPU usage, and PF/VF virtualization configurations.
Confirm deployed kernel packages include one of the referenced stable fixes.
Identify which tenants or workloads can control provisioned GPU virtual functions.
After updating, verify GPU virtualization and LMEM provisioning operate normally.
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-38511 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.