drm/buddy: oversized contiguous VRAM request rounds past the pool size and hits BUG_ON, panicking the node
Impact
The DRM buddy allocator rounds a requested VRAM allocation up - to the next power of two for DRM_BUDDY_CONTIGUOUS_ALLOCATION, or up to min_block_size for large-block requests - without re-checking the result against the size of the memory pool. A 9 GiB contiguous request against a 10 GiB VRAM pool rounds to 16 GiB, which then trips BUG_ON(order > mm->max_order): the kernel does not return an error, it panics. The requested size comes from userspace, so on any node whose GPU driver uses drm/buddy for device memory (amdgpu, xe, i915) a tenant that can submit buffer allocations can choose a size that takes the host down. That is a one-call denial of service across a tenancy boundary on exactly the machines that are most expensive to lose: a panic drops every co-resident job and the node returns only after a reboot and GPU re-init. The fix returns -EINVAL for the invalid non-contiguous and range cases and lets contiguous requests fall through to the existing __alloc_contig_try_harder() path instead of asserting.
Who can reach it
Local, authenticated: any tenant with access to a DRM render node (/dev/dri/renderD*) on a GPU using the drm/buddy VRAM allocator, able to request a buffer whose rounded size exceeds the VRAM pool. No privilege beyond device access; a GPU pod is enough.
What to do
Deploy a stable kernel containing the drm/buddy rounded-size validation, then drain and reboot each GPU node - the allocator is in the DRM core, so unloading or reloading the GPU driver module does not pick up the fix. There is no supported runtime mitigation that caps the rounded size; the only interim lever is not exposing DRM render nodes to untrusted tenants on affected hosts, which for most GPU clouds is not an option. Schedule this one ahead of the cosmetic kernel fixes in the same batch: the trigger is user-controlled and the outcome is a panic.
References
Related entries
- Linux kernel amdgpu display core (DC/DM) (drm/amd/display): A correctness defect in the amdgpu display core (DC/DM)CVE-2026-43191 · Linux kernel amdgpu display core (DC/DM) (drm/amd/display)Medium
- Linux kernel amdgpu user-mode queues (doorbell submission path) (drm/amdgpu): Missing or insufficient validation ofCVE-2026-43195 · Linux kernel amdgpu user-mode queues (doorbell submission path) (drm/amdgpu)Medium
- Linux kernel amdgpu display core (DC/DM) (drm/amd/display): A correctness defect in the amdgpu display core (DC/DM)CVE-2026-43243 · Linux kernel amdgpu display core (DC/DM) (drm/amd/display)Medium
- Linux kernel DRM: property blob allocations escape cgroup accounting, letting a local user exhaust kernel memoryCVE-2026-43287 · Linux kernel DRM property blobs (DRM_IOCTL_MODE_CREATEPROPBLOB allocations not charged to memcg)Medium
- Linux kernel amdgpu display core (DC/DM) (drm/amdgpu): A race condition or locking defect in the amdgpu display coreCVE-2026-43298 · Linux kernel amdgpu display core (DC/DM) (drm/amdgpu)Medium
- Linux kernel amdgpu display core (DC/DM) (drm/amd/display): A race condition or locking defect in the amdgpu displayCVE-2026-43305 · Linux kernel amdgpu display core (DC/DM) (drm/amd/display)Medium
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.