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