CVE-2026-80702: drm/vmwgfx: fix guest_memory_dirty bitfield clobbered as size
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: fix guestmemorydirty bitfield clobbered as size
Two sites in vmwgfxresource.c assign boolean literals to res->guestmemorysize, which is an unsigned long allocation-size field; the intended target is the adjacent res->guestmemorydirty bitfield. After the assignments the field holds 0 or 1 instead of the resource's MOB allocation size:
- vmwresourcerelease() writes 0 (false), and - vmwresourceunbindlist() writes 1 (true).
Subsequent revalidation paths read guestmemorysize when computing the dirty page range (vmwbodirtytransfertores()) and the buffer allocation size (vmwresourcebufalloc()), producing zero-length walks or wrap-around ranges that read or write past the MOB bitmap. The dirty-tracking intent of the original code (mark the resource as dirtied since the last sync) is also lost, since guestmemorydirty is never updated.
Rename both assignments to guestmemorydirty.
Affected Software
Event History
Frequently Asked Questions
Which resource lifecycle paths can lead to the corrupted allocation-size state?
The incorrect writes occur in vmw_resource_release(), which stores 0, and vmw_resource_unbind_list(), which stores 1, into guest_memory_size. Later resource revalidation can consume that corrupted value in vmw_bo_dirty_transfer_to_res() and vmw_resource_buf_alloc().
What failures can result once the resource is revalidated?
A zero or one value in the allocation-size field can cause zero-length dirty-page walks or wrap-around ranges. Those ranges can read or write beyond the MOB bitmap, while the intended dirty-state tracking is also not updated.