Linux kernel (drivers/gpu/drm): Three lines of userspace - mmap a GEM object with PROT_WRITE and MAP_PRIVATE, then

Impact

Three lines of userspace - mmap a GEM object with PROT_WRITE and MAP_PRIVATE, then write to it - hit a BUG_ON and panic the kernel. Any tenant can reboot the node out from under every other tenant on it, with no race and no setup. The upstream fix states this affects every DRM driver using the default shmem helpers.

Who can reach it

Unprivileged process holding /dev/dri/renderD* on any shmem-helper driver. In a GPU fleet the datacenter-relevant instance is virtio-gpu inside a tenant VM, and any node running vkms/panfrost-class drivers. Reproducer is published in the commit message.

What to do

Update to a stable kernel carrying the fix (commits below; no fixed_in published). Interim: remove /dev/dri from guests and containers that do not need GPU access - there is no way to block the mmap flags from userspace policy.

References

Related entries

• 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
• Linux kernel (drivers/gpu/drm): The shared GPU SVM layer mis-computes the mapping order when an HMM range onlyCVE-2025-40336 · Linux kernel (drivers/gpu/drm)High
• 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/vfio/pci): An uninitialized stack variable is used as the device count when a tenant asks vfioCVE-2024-41052 · Linux kernel (drivers/vfio/pci)Medium