Severity by source
AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Local ioctl access with low privileges (PR:L), a timing race against page-clearing makes it AC:H, and CWE-524 is pure disclosure so C:H with I:N/A:N.
Primary rating from NVD.
CVSS VectorNVD
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Lifecycle Timeline
5DescriptionNVD
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/uapi: Reject coh_none PAT index for CPU cached memory in madvise
Add validation in xe_vm_madvise_ioctl() to reject PAT indices with XE_COH_NONE coherency mode when applied to CPU cached memory.
Using coh_none with CPU cached buffers is a security issue. When the kernel clears pages before reallocation, the clear operation stays in CPU cache (dirty). GPU with coh_none can bypass CPU caches and read stale sensitive data directly from DRAM, potentially leaking data from previously freed pages of other processes.
This aligns with the existing validation in vm_bind path (xe_vm_bind_ioctl_validate_bo).
v2(Matthew brost)
- Add fixes
- Move one debug print to better place
v3(Matthew Auld)
- Should be drm/xe/uapi
- More Cc
v4(Shuicheng Lin)
- Fix kmem leak issues by the way
v5
- Remove kmem leak because it has been merged by another patch
v6
- Remove the fix which is not related to current fix
v7
- No change
v8
- Rebase
v9
- Limit the restrictions to iGPU
v10
- No change
(cherry picked from commit 016ccdb674b8c899940b3944952c96a6a490d10a)
AnalysisAI
Information disclosure in the Linux kernel's Intel Xe DRM graphics driver (drm/xe) allows a local user to read stale data from previously freed memory pages belonging to other processes. The xe_vm_madvise_ioctl() handler failed to reject PAT indices set to XE_COH_NONE (non-coherent) coherency mode on CPU-cached buffer objects, letting a GPU bypass dirty CPU caches and read sensitive content directly from DRAM before the kernel's page-clearing writeback completes. There is no public exploit identified at time of analysis, and EPSS rates exploitation probability at just 0.02%, consistent with a local, race-dependent leak rather than a widely weaponized flaw.
Technical ContextAI
The vulnerability lives in the Intel Xe kernel-mode DRM driver, which manages modern Intel integrated and discrete GPUs and exposes a uAPI for userspace graphics/compute clients. PAT (Page Attribute Table) indices control GPU memory coherency; the XE_COH_NONE mode tells the GPU it need not snoop CPU caches. When the kernel zeroes freed pages before reallocation, those writes can remain dirty in the CPU cache and not yet be flushed to DRAM. A GPU mapping configured with coh_none bypasses that cache and reads directly from DRAM, observing the stale, uncleared contents of pages previously owned by other processes. The root cause maps to CWE-524 (Use of Cache Containing Sensitive Information): the madvise path lacked the coherency validation already present in the vm_bind path (xe_vm_bind_ioctl_validate_bo), creating an inconsistent enforcement gap. Per the v9 revision note, the final fix limits the restriction to integrated GPUs (iGPU). CPE data identifies the affected product as cpe:2.3:a:linux:linux, i.e., the Linux kernel itself.
RemediationAI
Vendor-released patch: update to a fixed Linux stable kernel - 6.18.32, 7.0.9, or 7.1-rc2 (or later) - which adds the missing coh_none/CPU-cached validation to xe_vm_madvise_ioctl(). The fix is delivered as upstream stable commits available at https://git.kernel.org/stable/c/87f9b1528e1ffc1da3615d552c9a06aba5e20b00, https://git.kernel.org/stable/c/fea04cf6f2345bc50f15b6638906c35962b89424, and https://git.kernel.org/stable/c/4e5591c2fc1b30f4ea5e2eab4c3a695acc404e39; for enterprise distributions, apply the corresponding vendor kernel update tracked at https://access.redhat.com/security/cve/CVE-2026-46309. If immediate patching is not possible, compensating controls include restricting access to the GPU render/DRI device nodes (e.g., tightening /dev/dri permissions and group membership) so only trusted users can issue the madvise ioctl, which limits the local attacker pool at the cost of breaking GPU access for unprivileged graphics/compute workloads. On affected systems where the Xe iGPU driver is not required, blacklisting or unloading the xe module removes the attack surface entirely but disables hardware acceleration for that GPU.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-35119
GHSA-vpjp-gfpq-57c9