Linux kernel (drivers/gpu/drm): The shared VRAM buddy allocator reports success for a ranged allocation it never

Impact

The shared VRAM buddy allocator reports success for a ranged allocation it never actually satisfied. The caller then treats memory it does not own as its own buffer, so one tenant's buffer object can overlap VRAM the allocator subsequently hands to another tenant - corruption in both directions and a read path into someone else's frame data.

Who can reach it

Any tenant holding /dev/dri/renderD* on a driver built on drm_buddy (amdgpu, i915, xe) can drive it: fragment or exhaust VRAM, then request ranged allocations until one hits the corner case. Purely local, no capabilities, no display access needed.

What to do

Boot a kernel with the drm_buddy fix (stable commits below; no fixed_in published). There is no meaningful interim control short of not sharing a GPU between tenants - the allocator is on every VRAM allocation path.

References

Related entries

• 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): The shared shmem GEM mmap helper dropped a reference it never owned, so the bufferCVE-2022-48981 · Linux kernel (drivers/gpu/drm)High
• Linux i915 GPU kernel driver: A use-after-free in the i915 GPU kernel driver. The general shape is that a GPU object isCVE-2024-26939 · Linux i915 GPU kernel driverHigh