CVE-2026-64098: Linux Kernel Race Condition Vulnerability

CVE-2026-64098 Overview

CVE-2026-64098 is a Linux kernel vulnerability in the virtio GPU driver (drm/virtio). The flaw exists in virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush(), which acquire a framebuffer buffer object's dma_resv lock via virtio_gpu_array_lock_resv() but ignore its return value. When the lock acquisition fails with -EINTR or -ENOMEM, subsequent calls to dma_resv_add_fence() proceed without holding the required lock. This triggers a lockdep assertion and races with concurrent readers or writers of the fence list, potentially corrupting kernel memory structures.

Critical Impact
A local attacker can trigger kernel memory corruption through the DRM cursor ioctl path, leading to potential privilege escalation or denial of service on systems using virtio GPU drivers.

Affected Products

Linux kernel with drm/virtio driver enabled
Virtualized guests using virtio GPU (QEMU/KVM, cloud instances)
Multiple stable kernel branches prior to the fix commits

Discovery Timeline

2026-07-19 - CVE-2026-64098 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-64098

Vulnerability Analysis

The vulnerability is a race condition combined with a locking error [CWE-667] in the virtio GPU DRM driver. Both virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() call virtio_gpu_array_lock_resv() to acquire the framebuffer buffer object's dma_resv lock. The return value is discarded. Two failure modes leave the lock unheld: -EINTR returned by dma_resv_lock_interruptible() when a signal interrupts the wait, and -ENOMEM returned by dma_resv_reserve_fences() during fence slot allocation.

After the failed acquisition, the queue path continues into virtio_gpu_array_add_fence(), which invokes dma_resv_add_fence(). This function requires the caller to hold the lock and asserts via dma_resv_assert_held(). With lockdep enabled, a warning fires at drivers/dma-buf/dma-resv.c:296. Beyond the assertion, mutating the dma_resv fence list without the lock races with concurrent readers and writers, corrupting the linked list.

Root Cause

Both call sites execute inside the .atomic_update plane callback. DRM atomic helpers do not permit this callback to fail because the commit has already been signed off to userspace with no rollback path. Moving lock acquisition to .prepare_fb was rejected due to deadlocks with other buffer object locking paths in the same atomic commit.

Attack Vector

The bug was reported by syzbot using fault injection (fail_nth) on the DRM_IOCTL_MODE_CURSOR path, forcing the -ENOMEM branch in dma_resv_reserve_fences(). A local unprivileged user with access to /dev/dri/card* can invoke drm_mode_cursor_ioctl repeatedly under memory pressure or signal delivery to trigger the unlocked fence list mutation. The fix introduces virtio_gpu_lock_one_resv_uninterruptible() using dma_resv_lock() instead of the interruptible variant, eliminating the -EINTR failure mode, and properly checks the return value to handle the remaining -ENOMEM case by freeing the objects and skipping the plane update.

Detection Methods for CVE-2026-64098

Indicators of Compromise

Kernel warning traces referencing dma_resv_add_fence+0x71e/0x840 at drivers/dma-buf/dma-resv.c:296
Stack traces including virtio_gpu_array_add_fence, virtio_gpu_queue_ctrl_sgs, and drm_mode_cursor_ioctl
Unexpected kernel oops or list corruption warnings involving dma_resv structures on virtio GPU guests

Detection Strategies

Enable CONFIG_PROVE_LOCKING and lockdep in kernel builds to surface dma_resv_assert_held() violations at runtime
Monitor dmesg and journalctl -k for WARN traces originating from the drm/virtio subsystem
Audit installed kernel versions against the fix commits referenced on kernel.org to identify vulnerable hosts

Monitoring Recommendations

Collect kernel log telemetry from virtualized workloads and forward to a centralized analytics platform for anomaly review
Track processes issuing high-frequency DRM_IOCTL_MODE_CURSOR syscalls on virtio GPU guests
Alert on repeated kernel warnings referencing virtio_gpu_ functions, which may indicate exploitation attempts

How to Mitigate CVE-2026-64098

Immediate Actions Required

Apply the upstream kernel patches referenced in the fix commits (21ab64c, 7930eee, 8fadd01, 9af1b6e, a2359a4, c86077d) as soon as your distribution provides them
Prioritize patching multi-tenant virtualization hosts where untrusted guest workloads run
Restrict access to /dev/dri/* device nodes to trusted users where feasible

Patch Information

Fixes are available in the mainline and stable trees. See Kernel Git Commit 21ab64c, Kernel Git Commit 7930eee, Kernel Git Commit 8fadd01, Kernel Git Commit 9af1b6e, Kernel Git Commit a2359a4, and Kernel Git Commit c86077d. The fix introduces virtio_gpu_lock_one_resv_uninterruptible() and checks the return value at both call sites to handle -ENOMEM gracefully.

Workarounds

Disable the virtio GPU driver on guests that do not require accelerated graphics by blacklisting the virtio_gpu module
Use alternative display backends such as VGA or Cirrus on virtualization hosts where feasible
Apply seccomp or LSM policies to restrict ioctl access on DRM devices for untrusted workloads

bash

# Blacklist the virtio_gpu module until the kernel is patched
echo "blacklist virtio_gpu" | sudo tee /etc/modprobe.d/blacklist-virtio-gpu.conf
sudo update-initramfs -u
sudo reboot

# Verify installed kernel version after patching
uname -r