CVE-2026-46309

What it actually does

This is a Linux kernel information disclosure flaw in the Intel Xe DRM GPU driver. The vulnerable path is the xe_vm_madvise_ioctl() userspace API, which did not reject a PAT index using XE_COH_NONE coherency for CPU-cached memory on affected integrated GPU configurations. Because CPU cache-cleared pages may remain dirty in CPU cache while the GPU reads directly from DRAM when coherency is disabled, a local process with access to the Xe GPU device can potentially read stale contents from previously freed physical pages. The exposed data may belong to other processes that previously used those pages. The issue is a confidentiality breach rather than code execution or privilege escalation by itself.

Why it matters to the business

On systems using the affected Linux kernel Xe GPU driver, an untrusted local user or workload with GPU device access may be able to recover sensitive data left in memory by other processes. This is most relevant for shared workstations, multi-user servers, container hosts, VDI, CI/build systems, and GPU-enabled compute environments where multiple users or jobs share the same kernel and GPU. Although EPSS is low and there is no known CISA KEV listing or public exploit maturity reported, the impact can still be material where secrets, documents, credentials, model data, or customer data may be processed on shared systems.

How an attack unfolds

An attacker first obtains local code execution as an unprivileged user or workload on a system using the vulnerable Xe DRM driver and with permission to access the GPU render node, typically through /dev/dri/renderD* or a similar DRM device. The attacker allocates CPU-cached GPU-accessible memory, then invokes the Xe VM madvise ioctl with a PAT index that maps to XE_COH_NONE coherency. Because the vulnerable kernel path accepts that incompatible combination, the GPU may read memory directly from DRAM while bypassing dirty CPU cache lines that contain the kernel's page-clearing writes. The attacker then uses GPU operations to inspect data returned from physical pages that were recently freed and reallocated, potentially recovering stale data from another process. Successful exploitation is local, requires suitable hardware and driver exposure, and may leave little or no conventional evidence beyond unusual DRM/Xe ioctl activity.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the upstream fix rejecting XE_COH_NONE PAT indices for CPU-cached memory in xe_vm_madvise_ioctl(), corresponding to upstream commit 016ccdb674b8c899940b3944952c96a6a490d10a or the applicable distribution backport. Because no exact fixed package versions were provided, use the relevant Linux distribution, appliance, or hardware vendor advisory to identify the fixed kernel build. If immediate patching is not possible, reduce exposure by restricting access to /dev/dri/* GPU device nodes to trusted users only, disabling untrusted GPU workloads, avoiding multi-tenant sharing of affected GPU-enabled hosts, and using cgroup, container runtime, udev, or device-plugin policy to prevent untrusted containers from receiving DRM render device access. Reboot after applying the fixed kernel so the patched driver is loaded.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix or upstream-equivalent patch for the Xe DRM madvise validation issue. Validate by checking the installed and running kernel package version against the distribution advisory, not only the package present on disk. Where source or symbols are available, verify that xe_vm_madvise_ioctl() rejects PAT indices whose coherency mode is XE_COH_NONE when applied to CPU-cached memory on affected iGPU paths. Operationally, confirm that untrusted users and containers cannot access /dev/dri/renderD* or /dev/dri/card* unless GPU access is explicitly required. After remediation, reboot and verify the active kernel with uname -a or the platform's kernel inventory tooling. A negative functional test should show the invalid madvise/PAT/coherency combination failing rather than being accepted.

Typical attack path

1. Gain local execution on a Linux system using the affected Intel Xe DRM kernel driver.
2. Confirm access to a DRM render or card device associated with the Xe GPU, such as /dev/dri/renderD* or /dev/dri/card*.
3. Allocate GPU-accessible CPU-cached buffer memory through the Xe DRM userspace API.
4. Invoke the Xe VM madvise ioctl using a PAT index with XE_COH_NONE coherency where it should have been rejected.
5. Trigger GPU reads that bypass CPU caches and access DRAM directly.
6. Scan returned buffer contents for stale data from previously freed pages, such as secrets, tokens, documents, or other process memory fragments.
7. Repeat allocation and read patterns to increase the chance of recovering sensitive data.

How to detect it

There are no known public exploit indicators, no KEV listing, and no stable file, process, network, or registry artifacts uniquely associated with exploitation. Detection should focus on exposure and suspicious local behavior. Useful sources include Linux auditd logs for access to /dev/dri/renderD* and /dev/dri/card*, eBPF or syscall tracing for DRM ioctl activity, process accounting, container runtime logs showing GPU device mounts, Kubernetes audit/device-plugin logs, and EDR telemetry for processes unexpectedly interacting with DRM render nodes. Look for untrusted or unusual processes repeatedly opening Xe DRM devices and issuing high volumes of ioctl calls consistent with buffer allocation, VM binding, and madvise operations. Kernel logs may help identify the presence of the xe driver, but successful exploitation is unlikely to produce a clear kernel error. If suspicious activity is found on an unpatched shared host, investigate recently running workloads and consider rotating secrets that may have resided in memory.

What your security team should do

• Prioritize patching shared, multi-user, containerized, VDI, CI, and GPU-enabled compute systems where untrusted users or workloads can access Intel Xe DRM devices.
• Inventory Linux systems exposing /dev/dri/renderD* or /dev/dri/card* and determine whether they use the Xe DRM driver and an affected kernel build.
• Apply the vendor-fixed kernel package and reboot; confirm the running kernel, not just the installed package, is remediated.
• Until patched, restrict DRM render-node access to trusted users and remove GPU device passthrough from untrusted containers or jobs.
• Review user, container, and workload access to GPU devices and enforce least privilege using udev rules, group membership, cgroups, Kubernetes device-plugin policy, or container runtime controls.
• Monitor for unusual local GPU API activity from unexpected users or processes, especially repeated DRM ioctl usage against Xe render nodes on shared systems.
• Treat suspected exploitation as a potential local memory disclosure event and assess whether secrets processed on the host should be rotated.