Linux kernel (drivers/gpu/drm): Three lines of userspace - mmap a GEM object with PROT_WRITE and MAP_PRIVATE, then

Impact

Three lines of userspace - mmap a GEM object with PROT_WRITE and MAP_PRIVATE, then write to it - hit a BUG_ON and panic the kernel. Any tenant can reboot the node out from under every other tenant on it, with no race and no setup. The upstream fix states this affects every DRM driver using the default shmem helpers.

Who can reach it

Unprivileged process holding /dev/dri/renderD* on any shmem-helper driver. In a GPU fleet the datacenter-relevant instance is virtio-gpu inside a tenant VM, and any node running vkms/panfrost-class drivers. Reproducer is published in the commit message.

What to do

Update to a stable kernel carrying the fix (commits below; no fixed_in published). Interim: remove /dev/dri from guests and containers that do not need GPU access - there is no way to block the mmap flags from userspace policy.

References