Linux kernel (drivers/gpu/drm/virtio): GEM handle values are guessable, and the driver dereferences the buffer object

Impact

GEM handle values are guessable, and the driver dereferences the buffer object after dropping the handle's reference, so a tenant that races object creation against a close of the guessed handle gets a use-after-free on a kernel object. That is an exploitable heap primitive from an unprivileged process inside the guest, i.e. container-to-guest-kernel privilege escalation.

Who can reach it

Any process inside a VM tenant holding /dev/dri/renderD* on a virtio-gpu device: two threads, one creating GEM objects, one closing the guessed handle number in a loop. Requires only the render node - no display access, no master, no host root. Reachable for any tenant given a virtio-gpu device (paravirtual GPU / vGPU-backed VMs).

What to do

Boot a kernel carrying the virtgpu handle-creation fix below. Interim: remove /dev/dri/renderD* from workloads that do not actually need virtio-gpu acceleration, and prefer passing a real GPU device rather than virtio-gpu where a hostile guest process is in the threat model.

References