CVE-2026-98609: Linux Kernel DRM Virtio Memory Leak Flaw

CVE-2026-98609 Overview

CVE-2026-98609 is a memory leak vulnerability in the Linux kernel's drm/virtio driver. The flaw resides in virtio_gpu_gem_create(), which incorrectly calls drm_gem_object_release() on the error path of drm_gem_handle_create() instead of dropping the reference taken by virtio_gpu_object_create(). This causes the buffer object to remain at refcount 1 with no owner, leaking shmem pages, the scatter-gather table, the virtio_gpu_object structure, and the host-side resource identifier. The upstream kernel fix replaces the incorrect release call with drm_gem_object_put() to match the success path.

Critical Impact
Repeated triggering of the failure path exhausts guest memory and host-side virtio-gpu resource IDs, enabling a local denial-of-service against virtualized graphics workloads.

Affected Products

Linux kernel drm/virtio driver (virtio-gpu)
Guest virtual machines using the virtio-gpu paravirtualized graphics device
Downstream distributions shipping affected stable kernel branches prior to the backported fixes

Discovery Timeline

2026-10-18 - CVE-2026-98609 published to NVD
2026-10-19 - Last updated in NVD database

Technical Details for CVE-2026-98609

Vulnerability Analysis

The defect is a resource lifecycle error [CWE-401] in the virtio-gpu Direct Rendering Manager (DRM) backend. virtio_gpu_gem_create() owns the reference produced by virtio_gpu_object_create(). When drm_gem_handle_create() fails, the function invokes drm_gem_object_release() to clean up. That routine is the inverse of drm_gem_object_init() and does not decrement the reference count or call obj->funcs->free(). It is only correct as the final step inside a destructor such as virtio_gpu_cleanup_object().

Using drm_gem_object_release() on an error path leaves the buffer object at refcount 1 with no remaining owner. The destructor virtio_gpu_free_object() is never invoked, so the shmem backing pages, the scatter-gather table, and the virtio_gpu_object allocation remain in memory. Because virtio_gpu_object_create() has already set bo->created, the VIRTIO_GPU_CMD_RESOURCE_UNREF command is also never queued to the host, leaking the host-side resource and its resource ID.

Root Cause

The root cause is incorrect pairing of initialization and teardown APIs. drm_gem_handle_create_tail() already drops the handle reference on all of its internal error paths. The caller is only responsible for dropping its own reference. The fix substitutes drm_gem_object_put() for drm_gem_object_release(), which decrements the refcount and triggers the proper destructor chain.

Attack Vector

An unprivileged local user in a guest VM with access to the DRM render node can repeatedly invoke the GEM create ioctl and force drm_gem_handle_create() to fail. Each failed call leaks guest memory and consumes a host-side virtio-gpu resource ID. Sustained invocation exhausts allocatable memory in the guest and may degrade the host virtio-gpu backend. The flaw is not remotely reachable and does not grant code execution or privilege escalation.

See the upstream fix in Linux Kernel Commit 13423a0 and parallel stable backports for technical details.

Detection Methods for CVE-2026-98609

Indicators of Compromise

Steady growth in guest kernel slab usage for virtio_gpu_object allocations without corresponding frees
Increasing count of allocated virtio-gpu resource IDs on the host without matching RESOURCE_UNREF commands
Guest processes repeatedly invoking DRM_IOCTL_VIRTGPU_RESOURCE_CREATE or related GEM create ioctls followed by failures

Detection Strategies

Monitor /proc/slabinfo on affected guests for anomalous growth in shmem and DRM-related caches
Audit kernel versions across the fleet and flag hosts and guests running unpatched drm/virtio builds
Correlate per-process DRM ioctl rates with memory pressure events to identify abusive callers

Monitoring Recommendations

Collect kernel version inventory from Linux endpoints and virtualization hosts
Alert on sustained memory growth in guest VMs that correlates with DRM device activity
Track hypervisor logs for virtio-gpu resource allocation anomalies

How to Mitigate CVE-2026-98609

Immediate Actions Required

Identify all Linux systems running the drm/virtio driver, including guest VMs with virtio-gpu passthrough
Apply the stable kernel updates containing the backported fix as soon as distribution packages become available
Restrict access to DRM render nodes for untrusted local users in multi-tenant guest environments

Patch Information

The fix replaces drm_gem_object_release() with drm_gem_object_put() in virtio_gpu_gem_create(). Upstream and stable backports are available in the following commits: 13423a0, 264ae8a, 36570ef, 372e9c3, 687be2f, a93dce1, e2edd2d, and f75066c. Rebuild and reboot guests after applying vendor kernel updates.

Workarounds

Tighten permissions on /dev/dri/renderD* so only trusted users or groups can issue GEM ioctls
Where virtio-gpu is not required, remove or blacklist the virtio_gpu kernel module in guest images
Apply per-VM memory limits in the hypervisor to contain the impact of guest-side memory exhaustion

bash

# Example: restrict render node access and blacklist the driver where unused
sudo chgrp render /dev/dri/renderD128
sudo chmod 0660 /dev/dri/renderD128
echo "blacklist virtio_gpu" | sudo tee /etc/modprobe.d/blacklist-virtio-gpu.conf
sudo update-initramfs -u