Cloudanix VulnDB

CVE-2026-98609

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A small mistake in graphics driver error handling can slowly leak memory and graphics resources until the system becomes unusable.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Theoretical
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Incorrect error handling in virtio_gpu_gem_create leaves a GEM object at refcount 1 after drm_gem_handle_create failure, preventing virtio_gpu_free_object from running and leaking shmem pages, sg tables, the object itself, and the corresponding host-side virtio-gpu resource.

Why it matters to the business

Repeated triggering of the error path gradually exhausts kernel memory and host GPU resources on systems using virtio-gpu, potentially causing denial of service or forcing restarts in virtualized environments that rely on this driver.

How an attack unfolds

An attacker with local access crafts GPU operations that cause drm_gem_handle_create to fail after virtio_gpu_object_create has succeeded; the flawed error path leaks the object instead of releasing it, accumulating leaks over many attempts until memory or resource limits are hit.

How to fix it

Update the Linux kernel to a version containing the upstream fix that replaces drm_gem_object_release with drm_gem_object_put on the error path in virtio_gpu_gem_create.

How to confirm the fix worked

Confirm the presence of the corrected error-handling logic in virtio_gpu_gem_create (drm_gem_object_put call) via source inspection or kernel version check; monitor for absence of new object leaks under the previously failing conditions.

Typical attack path

  1. Obtain local unprivileged access on a Linux system using the virtio-gpu driver
  2. Issue sequences of DRM ioctls that trigger virtio_gpu_gem_create and force drm_gem_handle_create to fail
  3. Repeat to accumulate leaked kernel objects and host resources
  4. Observe system-wide memory pressure or GPU resource exhaustion

How to detect it

Review kernel logs for repeated virtio_gpu object allocation without matching release messages; correlate with processes performing DRM ioctls that frequently fail handle creation; inspect memory usage trends on virtio-gpu hosts.

What your security team should do

  • Prioritize kernel updates on all systems exposing virtio-gpu (virtual desktops, cloud instances, embedded devices)
  • Apply the fix within standard patch windows given low EPSS and absence from KEV
  • Include virtio-gpu driver files in kernel diff reviews for future updates

The record

In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix object leak when drm_gem_handle_create() fails virtio_gpu_gem_create() owns the reference taken by virtio_gpu_object_create(). On the drm_gem_handle_create() error path it calls drm_gem_object_release() instead of dropping that reference. drm_gem_object_release() is the inverse of drm_gem_object_init() and does not touch the reference count or call obj->funcs->free(), so it is only correct as the last step of a destructor, as in virtio_gpu_cleanup_object(). Using it here leaves the bo at refcount 1 with no remaining reference, so virtio_gpu_free_object() never runs and the shmem pages, sg table and virtio_gpu_object are leaked. Since virtio_gpu_object_create() has already set bo->created, VIRTIO_GPU_CMD_RESOURCE_UNREF is not queued either, leaking the host-side resource and the resource id. drm_gem_handle_create_tail() drops the handle reference on all of its internal error paths, so the caller only has to drop its own. Use drm_gem_object_put(), matching the success path below.

Affected packages

Ecosystem Package Introduced Fixed