Cloudanix VulnDB

CVE-2026-80888

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in the graphics driver lets ordinary users slowly consume memory until the computer becomes unusable or crashes.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Unconditional failure path in ttm_prime_fd_to_handle skips dma_buf_put after dma_buf_get when dma_buf->ops mismatch, leaking one reference per call and pinning the foreign GEM exporter's buffers.

Why it matters to the business

Unprivileged local users can gradually exhaust kernel memory and DMA buffers on systems using vmwgfx, eventually causing denial of service or forcing reboots; widespread on Linux desktops and VMs with 3D acceleration.

How an attack unfolds

A local unprivileged process opens a renderD node, crafts a prime fd from another driver, and repeatedly calls DRM_VMW_GB_SURFACE_REF or DRM_VMW_GB_SURFACE_REF_EXT; each call leaks a dma_buf reference until the system is starved of buffer objects.

How to fix it

Upgrade to a Linux kernel containing the referenced fix that routes the error path through dma_buf_put; rebuild and reboot all affected hosts or VMs.

How to confirm the fix worked

Confirm the patch is present by inspecting the drm/vmwgfx source for the dma_buf_put call in the ttm_prime_fd_to_handle error path; test by repeating the ioctl sequence and verifying no reference leak via /proc or bpftrace.

Typical attack path

  1. Obtain unprivileged shell on Linux host or VM exposing /dev/dri/renderD*
  2. Import a dma_buf fd whose ops vector does not match vmwgfx's ttm_object_device
  3. Invoke DRM_VMW_GB_SURFACE_REF_EXT ioctl in a tight loop
  4. Observe progressive increase in pinned dma_buf references and eventual OOM or GPU fault

How to detect it

Search kernel logs for repeated -ENOSYS returns from ttm_prime_fd_to_handle or vmwgfx ioctl paths; correlate with rising dma_buf reference counts visible via debugfs or bpf; watch for processes repeatedly calling DRM_VMW_GB_SURFACE_REF ioctls.

  • ttm_prime_fd_to_handle.*-ENOSYS
  • drm_ioctl.*DRM_VMW_GB_SURFACE_REF
  • dma_buf reference leak

What your security team should do

  • Prioritize kernel updates on all systems exposing vmwgfx render nodes to untrusted users
  • Restrict access to /dev/dri/renderD* via group membership or SELinux until patched
  • Monitor for sustained high dma_buf reference counts as an early indicator of exploitation

The record

In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: drop dma_buf reference on foreign-fd prime import ttm_prime_fd_to_handle() returns -ENOSYS when the imported fd's dma_buf->ops do not match the ttm_object_device's ops, but does so without releasing the reference acquired by dma_buf_get(). Any unprivileged renderD client passing a non-vmwgfx prime fd through the DRM_VMW_GB_SURFACE_REF{,_EXT} path leaks one dma_buf reference per call and indefinitely pins the foreign exporter's GEM resources. Funnel the error path through the existing dma_buf_put() so the reference is always dropped.

Affected packages

Ecosystem Package Introduced Fixed