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

Related entries

• Linux kernel (drivers/gpu/drm): The shared shmem GEM mmap helper dropped a reference it never owned, so the bufferCVE-2022-48981 · Linux kernel (drivers/gpu/drm)High
• Linux kernel (drivers/gpu/drm): The shared VRAM buddy allocator reports success for a ranged allocation it neverCVE-2024-26911 · Linux kernel (drivers/gpu/drm)High
• Linux kernel (drivers/gpu/drm): DRM core stores a pointer to the caller's struct pid before taking a reference on itCVE-2024-39486 · Linux kernel (drivers/gpu/drm)High
• Linux kernel (drivers/gpu/drm): Three lines of userspace - mmap a GEM object with PROT_WRITE and MAP_PRIVATE, thenCVE-2024-39497 · Linux kernel (drivers/gpu/drm)Medium
• Linux kernel (drivers/gpu/drm): The dma_buf pointer cached on a GEM object goes stale the moment userspace drops theCVE-2025-38674 · Linux kernel (drivers/gpu/drm)Medium
• CephFS kernel client (ceph.ko, MDS auth caps): In a multi-FS Ceph cluster the kernel client applies an MDS auth capCVE-2025-40362 · CephFS kernel client (ceph.ko, MDS auth caps)High