Linux kernel (drivers/gpu/drm): The shared shmem GEM mmap helper dropped a reference it never owned, so the buffer

Impact

The shared shmem GEM mmap helper dropped a reference it never owned, so the buffer object is freed while still mapped and still referenced - a use-after-free on a GEM object that the tenant continues to hold a mapping to. This is a strong exploitation primitive: the tenant keeps a live mapping over freed kernel-managed pages.

Who can reach it

A tenant process holding /dev/dri/renderD* on any driver built on the shmem GEM helpers (virtio-gpu and the shmem-backed DRM drivers) triggers it by mmap'ing a GEM object and forcing the helper's error path. Unprivileged, render-node only.

What to do

Boot a kernel carrying the drm_gem_shmem_helper fix below. Interim: remove /dev/dri/renderD* from untrusted containers on nodes whose DRM driver uses the shmem helpers.

References

Related entries

• 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
• 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/i915/gem): The access handler for a memory-mapped GEM object never bounds-checks theCVE-2022-49261 · Linux kernel (drivers/gpu/drm/i915/gem)High