Database/Kernel, userspace & hypervisor
Linux kernel (drivers/gpu/drm/xe): On SR-IOV-partitioned Intel GPUs, the local-memory translation tables handed to a VF
Impact
On SR-IOV-partitioned Intel GPUs, the local-memory translation tables handed to a VF are allocated without being zeroed, so page-table entries outside the range actually provisioned to that VF still point at whatever was there before - another tenant's VRAM allocations or the host PF's own pages. A malicious guest that walks past its provisioned LMEM window reads, and can write, memory belonging to a different tenant or to the host.
Who can reach it
A guest that owns an SR-IOV VF of the GPU (i.e. a VM tenant given a virtual function rather than a whole card) reaches this by simply addressing local memory beyond its provisioned range. Requires SR-IOV to be enabled and VFs provisioned by the xe PF driver; a plain container holding /dev/dri/renderD* on a non-virtualized card is not affected. No host root or physical access needed - the boundary broken is exactly the VF/PF partitioning boundary the operator is selling.
What to do
Boot a kernel carrying the fix commits below (no fixed_in version published by the kernel CNA - track the stable trees the commits landed in). Interim: stop provisioning GPU VFs to untrusted tenants, or disable SR-IOV on the xe cards and hand out whole devices instead, until the patched kernel is rolled out.
References
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.