Look up another CVE · open CVE-2026-80702 in the interactive tracker
CVE-2026-80702
drm/vmwgfx: fix guest_memory_dirty bitfield clobbered as size
Published 2026-08-28 (2 months ago) by the Linux kernel CNA. Subsystem drivers/gpu. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-80702 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | fixed | 6.12.105-1 | Update the kernel and reboot. Fixed in 6.12.105-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.8-1 | Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.8-1 | Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4788-1 · 2026-09-19 · text | 6.12.107-1~deb12u1 | Update the kernel and reboot. DLA-4788-1 shipped the fix on 2026-09-19, in 6.12.107-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
- What this is
- DRM DRIVER FOR VMWARE VIRTUAL GPUMAINTAINERS section matched on drivers/gpu/drm/vmwgfx/ · dri-devel@lists.freedesktop.org · Supported
- Kernel module
- vmwgfx
Check it on the machine
grep -w CONFIG_DRM_VMWGFX /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w vmwgfxPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le
- trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k
- M
- a module where it is built at all; some flavours do not build it
- Build switch
- CONFIG_DRM_VMWGFX
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-28 (2 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.13%, higher than 2.2% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/gpu
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.4 | 6.6.151 | 21bbe38faee4 |
| 6.4 | 6.12.103 | 9d6cbb76fe9c |
| 6.4 | 6.18.44 | 282f261cb035 |
| 6.4 | 7.1.8 | 3b2bb16a5b62 |
| 6.4 | 7.2 | 83195b778f2d |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4788-1 | 2026-09-19 | bookworm 6.12.107-1~deb12u1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- Reachable only via local DRM ioctls on the vmwgfx render node (surface/context create-unref, DRM_VMW_EXECBUF, synccpu); vmw_resource_unbind_list runs from vmw_bo_move_notify during MOB eviction, not from any network or physical bus.
- AC:LAttack complexity, low
- An unprivileged attacker controls the full GPU resource lifecycle and can force MOB moves plus subsequent revalidation (execbuf, memory pressure, destroy paths) to clobber guest_memory_size to 0/1 without races or victim-dependent heap layout.
- PR:LPrivileges required, low
- Entry ioctls use DRM_RENDER_ALLOW, so any local user with access to /dev/dri/renderD* on a VMware SVGA guest can trigger vmw_resource_release or vmw_resource_unbind_list and the follow-on validate/dirty paths without init-namespace root.
- UI:NUser interaction, none
- Exploitation requires only the attacker opening the DRM render device and issuing crafted GPU resource operations; no additional actions by another user or administrator are needed.
- S:UScope, unchanged
- The bug corrupts guest-kernel vmwgfx MOB dirty-tracking and heap metadata during resource revalidation; impact is confined to the guest kernel security domain and does not directly cross a VM/host or IOMMU boundary.
- C:HConfidentiality impact, high
- Clobbering guest_memory_size to 0 or 1 breaks dirty page-range math in vmw_bo_dirty_transfer_to_res and vmw_resource_buf_alloc, producing zero-length or wrap-around walks that read past the MOB dirty bitmap and adjacent kernel heap memory.
- I:HIntegrity impact, high
- The same corrupted size drives out-of-bounds bitmap_clear and dirty_sync operations past the MOB bitmap and undersized reallocations, yielding a kernel heap write primitive that can be leveraged for guest privilege escalation.
- A:HAvailability impact, high
- Out-of-bounds MOB bitmap access and mis-sized buffer reallocation during revalidation after unbind or release can kernel-oops or panic the guest, providing a reliable denial-of-service against the VM.