ZeroHour

CVE-2026-80702

large

Linux kernel vmwgfx driver misassignment enables out-of-bounds memory access

CVSS 3.1
7.8 high
EPSS
<1%p3
Published
()
Modified
AI analysis

The Linux kernel's vmwgfx DRM driver (the VMware SVGA virtual GPU driver) contains a coding error in which two sites in vmwgfx_resource.c assign boolean literals to res->guest_memory_size, an unsigned long field meant to hold the resource's MOB (guest memory buffer) allocation size, instead of the adjacent res->guest_memory_dirty bitfield: vmw_resource_release() writes 0 and vmw_resource_unbind_list() writes 1. During subsequent revalidation, paths such as vmw_bo_dirty_transfer_to_res() and vmw_resource_buf_alloc() read the corrupted size value, producing zero-length walks or wrap-around ranges that read or write past the MOB bitmap (out-of-bounds kernel memory access), while the intended dirty-tracking state is also lost. An attacker gains kernel memory disclosure or corruption with high confidentiality, integrity, and availability impact per the CVSS score of 7.8, implying likely local privilege escalation or a crash exploitable by a local, low-privileged user. Affected systems are Linux kernels whose vmwgfx_resource.c contains the erroneous assignments — in practice typically Linux guest VMs running on VMware hypervisors (ESXi, Workstation, Fusion) with the vmwgfx driver loaded; exact introduced/fixed kernel version ranges are not specified in the available data. Exploitation status: no public proof-of-concept is known, the flaw is not in CISA KEV, and EPSS estimates only a 0.1% probability of exploitation in the next 30 days, so no in-the-wild exploitation is known.

What to do: Update affected Linux guests to a kernel that includes the vmwgfx guest_memory_dirty fix, checking your distribution's backported kernel advisory since exact fixed version numbers are not enumerated in the available data. As an interim mitigation on VMware guests, prevent untrusted local users from gaining shell access, or blacklist/unload the vmwgfx module on guests that do not need the VMware virtual GPU. Prioritize patching multi-user or remotely-accessible Linux VMs on VMware hosts, since exploitation requires local low-privileged code execution.

Affected
Linux kernel — drm/vmwgfx (VMware SVGA) DRM driver
Estimated exposure
large≈100,000 systems (order of magnitude: VMware-hosted Linux guests running kernels with the vmwgfx driver loaded) — vmwgfx ships enabled in mainline and distro kernels as the default display/GPU driver for Linux guests on VMware ESXi/Workstation/Fusion, and public surveys place VMware-hosted Linux VMs in the hundreds of thousands; factoring in the…

Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.

Description

In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: fix guest_memory_dirty bitfield clobbered as size Two sites in vmwgfx_resource.c assign boolean literals to res->guest_memory_size, which is an unsigned long allocation-size field; the intended target is the adjacent res->guest_memory_dirty bitfield. After the assignments the field holds 0 or 1 instead of the resource's MOB allocation size: - vmw_resource_release() writes 0 (false), and - vmw_resource_unbind_list() writes 1 (true). Subsequent revalidation paths read guest_memory_size when computing the dirty page range (vmw_bo_dirty_transfer_to_res()) and the buffer allocation size (vmw_resource_buf_alloc()), 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 guest_memory_dirty is never updated. Rename both assignments to guest_memory_dirty.

Vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

In the news

No ingested article mentions this CVE yet.