Linux kernel (drivers/gpu/drm): The shared GPU SVM layer mis-computes the mapping order when an HMM range only

Impact

The shared GPU SVM layer mis-computes the mapping order when an HMM range only partially covers a huge page, so the driver programs GPU page-table entries for memory outside the range the tenant asked for - including pages not mapped by that process's mm at all. The GPU then reads and writes host memory the tenant was never granted, which is a direct route to another tenant's or the kernel's pages.

Who can reach it

A tenant container holding /dev/dri/renderD* on a driver using the shared GPU SVM/userptr path (xe, and drivers moving onto drm_gpusvm) reaches this from normal SVM/userptr binds - it only has to arrange a userspace range that straddles a transparent-huge-page boundary. No special capability, no display access, no host root.

What to do

Update to a kernel carrying the drm_gpusvm fix commits below (the kernel CNA published no fixed_in list; follow the stable branches these landed on). Interim: for untrusted tenants, disable transparent hugepages for the workload or drop /dev/dri/renderD* from containers that do not need GPU SVM.

References