Linux kernel drm/vmwgfx: undersized DMA command lets one command rewrite another's verified fields

Impact

vmw_cmd_dma located the DMA suffix by offsetting from the command body using a caller-supplied header->size, without checking the body was large enough to hold the suffix. An undersized header makes that pointer underflow into the preceding command in the bounce buffer, and the verifier's later write of suffix->maximumOffset clobbers fields of a command it had already validated and relocated. That is a TOCTOU on the device-visible command stream: one submitted command can rewrite another's GMR id, surface id or other authenticated fields, defeating the checks the verifier exists to enforce. Exposure is confined to systems where vmwgfx is loaded - VMware guests - so bare-metal NVIDIA or AMD GPU nodes are unaffected; virtualized management, build or VDI guests on ESXi in the same estate are the ones to look at.

Who can reach it

A local user inside a VMware guest holding an open DRM device or render node on the vmwgfx driver, able to submit command buffers. No remote path and no privileged account is needed, but the driver must actually be loaded - headless bare-metal accelerator nodes typically do not load it.

What to do

Take the stable kernel update carrying the fix (commits are linked on the record) for each affected guest series, then reboot the guest - a running kernel cannot be swapped in place here. Since the affected population is VMware guests rather than GPU compute nodes, this usually schedules as ordinary guest patching, not a fleet drain. Where a guest has no graphics workload at all, blacklisting or unloading vmwgfx removes the attack surface until the reboot.

References