Linux kernel drm/xe: GGTT MMIO access after the MMIO region is gone on failed load or teardown

CVSS 7.8CVE-2026-23466NVIDIA / GPU stackcurated

Impact

GGTT MMIO access in the Intel Xe GPU driver was guarded only by the hotplug (drm_dev_enter) path, which is never armed if driver load fails because drm_dev_unplug() is not called. Devm release ordering also does not guarantee that every buffer object holding a GGTT mapping is destroyed before the GGTT MMIO region goes away, since some BOs are freed asynchronously by worker threads. The result is MMIO access to a region that has already been torn down, which on a node with Intel datacenter GPUs means kernel memory corruption or a crash during driver load failure, unbind, or module unload. The practical exposure is narrow: it needs a driver load failure or an unbind, both of which are operator-initiated rather than tenant-initiated.

Who can reach it

Local. Triggered by driver load failure or by driver unbind/unload, which requires root on the host. A tenant with a GPU pod cannot reach it directly; the realistic case is a node that crashes or corrupts memory during a failed probe or a driver swap.

What to do

Update the host kernel or the xe driver to a build carrying the stable fix commits below, then drain and reboot each affected node - the fix is in the driver load and teardown path, so a live module reload is exactly the operation at risk. Only nodes running Intel GPUs with the xe driver are affected.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-23466 https://git.kernel.org/stable/c/01f2557aa684e514005541e71a3d01f4cd45c170 https://git.kernel.org/stable/c/76326dc06d8793c2c81c31cc0115dbc348de2f88

Related entries

All NVIDIA / GPU stack entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.