Linux kernel (drivers/gpu/drm/i915/gem): The access handler for a memory-mapped GEM object never bounds-checks the

Impact

The access handler for a memory-mapped GEM object never bounds-checks the requested length before the memcpy, so a tenant can read and write kernel memory adjacent to the object's mapping. Out-of-bounds read gives another tenant's leftover buffer contents; out-of-bounds write gives kernel heap corruption from an unprivileged process.

Who can reach it

A tenant process holding /dev/dri/renderD* on an i915 GPU maps a GEM object and then drives the vm_access path against it (process_vm_readv/writev or ptrace-style access to its own mapping, which is what the public PoC does). No privilege beyond the render node, no display access needed.

What to do

Boot a kernel carrying the i915 vm_access bounds-check fix below. Interim: drop /dev/dri/renderD* from containers that do not need i915 acceleration; there is no runtime toggle that closes this path while the device node is exposed.

References