Cloudanix VulnDB

CVE-2026-80702

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Aug 28, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A coding error in a graphics driver can let someone already on the machine corrupt memory, which might crash the system or let them take full control.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Incorrect boolean assignments overwrite an unsigned long allocation-size field instead of the adjacent dirty bitfield, causing subsequent dirty-page calculations and buffer allocations to compute zero-length or wrap-around ranges that read or write past the MOB bitmap.

Why it matters to the business

Local attackers can corrupt kernel memory on systems using the VMware graphics driver, risking crashes, data leakage, or privilege escalation that disrupts operations or compromises the host.

How an attack unfolds

A local attacker triggers resource release or unbind paths that clobber the size field, then forces revalidation routines to perform invalid memory walks that corrupt guest resources.

How to fix it

Apply the upstream kernel patch that renames the assignments to guest_memory_dirty; rebuild and deploy the corrected kernel on all affected systems.

How to confirm the fix worked

Inspect vmwgfx_resource.c to confirm the two assignments now target guest_memory_dirty, then run regression tests exercising resource release, unbind, and dirty-transfer paths.

Typical attack path

  1. Obtain local user privileges on an affected Linux system
  2. Exercise vmw_resource_release or vmw_resource_unbind_list paths
  3. Induce vmw_bo_dirty_transfer_to_res or vmw_resource_buf_alloc to perform out-of-bounds accesses

How to detect it

Review kernel logs for vmwgfx oops or warnings mentioning guest_memory_size or invalid MOB ranges; correlate with graphics-resource activity preceding the crash.

What your security team should do

  • Prioritize kernel updates on all VMware-accelerated Linux workloads
  • Limit local user access on graphics-enabled hosts until patched
  • Enable kernel memory-protection features such as KASAN in test environments to surface similar issues early

The record

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.

Affected packages

Ecosystem Package Introduced Fixed