CVE-2026-53190: Linux Kernel Privilege Escalation Flaw

CVE-2026-53190 Overview

CVE-2026-53190 is a reference count leak in the Linux kernel's VirtIO GPU driver (drm/virtio). The flaw resides in virtio_gpu_dma_fence_wait(), where an early return path inside dma_fence_unwrap_for_each() fails to release a dma_fence reference acquired by dma_fence_unwrap_first(). When virtio_gpu_do_fence_wait() returns an error mid-loop, the cursor chain reference is never decremented, leaking kernel memory associated with the fence object. This is the only kernel caller that performs an early return inside dma_fence_unwrap_for_each, making the issue site-specific. The fix adds an explicit dma_fence_put(itr.chain) before the early return.

Critical Impact
Repeated invocation of the faulty error path can exhaust kernel memory, leading to resource exhaustion in virtualized environments using VirtIO GPU.

Affected Products

Linux kernel versions containing the drm/virtiovirtio_gpu_dma_fence_wait() implementation prior to the fix
Guest systems using the VirtIO GPU driver with dma_fence_unwrap semantics
Virtualized environments leveraging VirGL/virtio-gpu fence synchronization

Discovery Timeline

2026-06-25 - CVE-2026-53190 published to NVD
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-53190

Vulnerability Analysis

The vulnerability is a memory leak rooted in mismatched reference counting on dma_fence objects. The macro dma_fence_unwrap_for_each() internally invokes dma_fence_unwrap_first(), which assigns cursor->chain = dma_fence_get(head) and acquires an extra reference on the head fence. Under normal loop completion, dma_fence_unwrap_next() triggers dma_fence_chain_walk(), which in turn calls dma_fence_put() to release the reference.

In virtio_gpu_dma_fence_wait(), the loop iterates over an unwrapped composite fence and calls virtio_gpu_do_fence_wait() for each component. When that call returns an error, the function returns immediately from inside the loop body. The natural cleanup path provided by dma_fence_unwrap_next() never executes, and the reference held in cursor->chain is never released.

Each failed wait leaks one dma_fence reference, preventing the underlying fence and its associated kernel structures from being freed. An attacker with the ability to repeatedly trigger fence wait failures from a guest can drive kernel memory exhaustion.

Root Cause

The root cause is an unbalanced reference count on the fence chain cursor when control flow exits the iteration macro abnormally. The dma_fence_unwrap_for_each API assumes callers run to loop completion so that dma_fence_unwrap_next() can perform the matching dma_fence_put(). virtio_gpu_dma_fence_wait() violates this contract by returning early on error without releasing itr.chain.

Attack Vector

A local user or guest workload submits VirtIO GPU operations that include composite dma_fence arrays. By crafting conditions under which virtio_gpu_do_fence_wait() returns an error, the attacker forces the early-return path. Repeated submissions accumulate leaked references, degrading host or guest stability over time. The vector requires interaction with the VirtIO GPU device interface and is not remotely exploitable without prior local access.

No public exploit code is available. The vulnerability is described in the upstream commits referenced by the Linux Kernel stable tree.

Detection Methods for CVE-2026-53190

Indicators of Compromise

Steady growth of kernel slab allocations associated with dma_fence objects without corresponding frees
Repeated error returns from virtio_gpu_do_fence_wait() visible in kernel ring buffer or tracing output
Unexpected memory pressure on systems running VirtIO GPU guests under sustained graphics workloads

Detection Strategies

Enable kernel kmemleak instrumentation to flag unreleased dma_fence allocations originating from drm/virtio call paths
Use ftrace or bpftrace to count entry and exit pairs in virtio_gpu_dma_fence_wait() and detect imbalance with dma_fence_put events
Audit installed kernel package versions against vendor advisories that reference the fix commits 3f26bb7, 73524e9, 8348567, 898bd0c, and c0fffc8

Monitoring Recommendations

Track /proc/slabinfo for unbounded growth in fence-related caches on virtualization hosts
Alert on guest processes that repeatedly trigger DRM ioctl errors against /dev/dri/cardN from the VirtIO GPU driver
Correlate guest GPU error rates with host memory consumption to surface gradual exhaustion patterns

How to Mitigate CVE-2026-53190

Immediate Actions Required

Apply the upstream kernel patches that add dma_fence_put(itr.chain) before the early return in virtio_gpu_dma_fence_wait()
Update to a Linux distribution kernel that includes the stable tree backports referenced in the advisory
Restrict access to /dev/dri/* device nodes inside guests to trusted users where feasible

Patch Information

The fix is committed to the upstream Linux kernel stable tree across multiple branches. Refer to the following commits: Linux Kernel Commit 3f26bb7, Linux Kernel Commit 73524e9, Linux Kernel Commit 8348567, Linux Kernel Commit 898bd0c, and Linux Kernel Commit c0fffc8. Rebuild and reboot affected kernels after applying.

Workarounds

Disable the VirtIO GPU driver (virtio_gpu) on guests that do not require accelerated graphics until the kernel is patched
Limit untrusted workloads from issuing arbitrary DRM ioctls that exercise composite fence synchronization
Monitor and recycle guests showing abnormal kernel memory growth before exhaustion impacts availability

bash

# Configuration example: blacklist the virtio_gpu module on guests not requiring it
echo "blacklist virtio_gpu" | sudo tee /etc/modprobe.d/blacklist-virtio-gpu.conf
sudo update-initramfs -u
sudo reboot