Linux kernel drm/xe: PF processes FAST_REQUEST and EVENT relay messages, breaking the VF/PF ABI

CVSS 8.4CVE-2026-72360NVIDIA / GPU stackcurated

Impact

The Intel Xe GPU driver's physical-function side attempted to handle VF/PF relay messages of types FAST_REQUEST and EVENT, although all defined relay actions use plain REQUEST messages. A virtual function sending one of the unexpected types breaks the VF/PF ABI protocol and can trip an assert on the PF side. On a host that slices Intel datacenter GPUs to guests via SR-IOV, this is a guest-to-host integrity and availability issue: a tenant VF driver can disturb the PF that every other VF on that device depends on, so the blast radius is the whole GPU rather than the one tenant. The record describes no information disclosure.

Who can reach it

Local to a guest holding an Intel Xe virtual function - the VF driver sends relay messages to the PF. No host authentication is involved; a tenant with an assigned VF is enough. Hosts not using Xe SR-IOV virtualization are not exposed.

What to do

Apply the stable kernel update that rejects FAST_REQ and EVENT relays on the PF (four stable branches carry the fix; see the git.kernel.org commits) and reboot each host running Intel Xe GPU virtualization - the driver is in use by live VFs, so a module reload is not realistic on a busy node. No vendor-published mitigation short of not exposing VFs.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-72360 https://git.kernel.org/stable/c/499be4b5d64209e9f18c9442f9fbeef7155ae900 https://git.kernel.org/stable/c/a4208d8032abd7f591581994f31e23b80b8fe659

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.