CVE-2026-64098

What it actually does

This is a Linux kernel race-condition/locking flaw in the virtio-gpu DRM driver. During cursor plane updates and resource flushes, the driver could continue as if a framebuffer buffer-object reservation lock was held even when lock acquisition failed due to signal interruption or fence-reservation allocation failure. The subsequent call path can add DMA reservation fences without holding the required lock, triggering kernel warnings and allowing concurrent mutation of the DMA reservation fence list. The practical result is kernel memory/list corruption risk in the graphics stack, which can lead to denial of service and may have confidentiality or integrity implications if corruption is exploitable in a given kernel build and configuration.

Why it matters to the business

Systems using Linux with virtio-gpu, especially virtual machines, desktop virtualization platforms, cloud guests, sandboxed graphical workloads, or CI/fuzzing environments that expose DRM devices to untrusted local users, could be crashed or destabilized by a low-privileged local user. Although there is no known public exploit maturity and EPSS is very low, the CVSS score reflects that successful exploitation could affect system confidentiality, integrity, and availability. Organizations running multi-user Linux systems or virtualized graphical workloads should prioritize kernel updates where virtio-gpu is enabled or accessible.

How an attack unfolds

An attacker first needs local code execution or an authenticated local session with access to the DRM device interface used by virtio-gpu. They then drive the DRM cursor/plane update path, such as through cursor update ioctls, while creating conditions that cause reservation-lock handling to fail or become racy. In the vulnerable code path, the virtio-gpu driver may ignore a failed reservation-lock acquisition and proceed to queue GPU work and add DMA reservation fences as though the lock were held. This can trip kernel lock assertions and, more importantly, race with other fence-list readers or writers, corrupting kernel-managed reservation data structures. Depending on timing, kernel configuration, and memory layout, the outcome may be a kernel warning, graphics subsystem failure, guest or host VM instability, kernel panic, or potentially broader local privilege-impacting memory corruption.

How to fix it

Upgrade to a Linux kernel version that includes the virtio-gpu fix changing the affected plane-update/resource-flush paths to use uninterruptible reservation locking for the single buffer object and to check the remaining allocation-failure case before proceeding. If vendor fixed versions are not yet available, apply the relevant upstream stable kernel patch once released by the distribution or kernel vendor. As interim mitigations, disable or avoid virtio-gpu where feasible, avoid exposing DRM devices to untrusted local users or containers, restrict graphical/session access on multi-user systems, and reduce attack surface by using alternative virtual GPU configurations where operationally acceptable. Because no exact affected product list or fixed package versions were provided, remediation should be tracked through the Linux distribution, hypervisor platform, or appliance vendor kernel advisory for this issue.

How to confirm the fix worked

Confirm the running kernel contains the virtio-gpu patch that introduces uninterruptible single-BO reservation locking for the affected cursor plane update and resource flush paths, and verifies the return value before queueing the update. Validate by checking the installed kernel package changelog or vendor advisory for this CVE or for the virtio-gpu dma_resv locking fix. On source-based or custom kernels, inspect the virtio-gpu DRM code to ensure virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() no longer ignore reservation-lock failure and do not call dma_resv_add_fence() unless the reservation lock is held. Operationally, confirm virtio-gpu is either not loaded where unnecessary or that access to /dev/dri devices is limited to trusted users and services. Review kernel logs after update to ensure the dma_resv_add_fence lock assertion warning no longer appears under normal graphical cursor/plane update activity.

Typical attack path

1. Obtain local execution on a Linux system where the virtio-gpu DRM driver is present and a DRM render/card device is accessible.
2. Interact with the DRM/KMS interface to trigger cursor or plane update operations handled by virtio_gpu_cursor_plane_update() or related resource flush paths.
3. Induce or race a failure in reservation-lock or fence-slot handling, such as through signal timing, memory pressure, or fault-like conditions.
4. Cause the vulnerable path to continue without the required dma_resv lock being held.
5. Trigger dma_resv_add_fence() on an improperly locked reservation object, causing a kernel warning, race, or reservation fence-list corruption.
6. Leverage the resulting instability for denial of service, or in a more advanced scenario attempt to shape the corruption for broader local impact.

How to detect it

Look for evidence of prior exploitation or attempted triggering in kernel logs, persistent journal records, crash dumps, hypervisor guest logs, and endpoint telemetry that captures ioctl-heavy graphics activity. Primary log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/crash, kdump/vmcore metadata, and hypervisor console logs for Linux guests. Search for kernel WARN/Oops/panic messages referencing dma_resv_add_fence, dma_resv_assert_held, virtio_gpu_array_add_fence, virtio_gpu_queue_ctrl_sgs, virtio_gpu_queue_fenced_ctrl_buffer, virtio_gpu_cursor_plane_update, virtio_gpu_resource_flush, drm_mode_cursor_ioctl, or DRM_IOCTL_MODE_CURSOR. Correlate these events with local user sessions, container starts, graphical applications, fuzzing tools, repeated cursor/DRM ioctl activity, memory-pressure events, or unexplained guest reboots. There are no known public threat actors or ransomware campaigns associated with this issue, so detection should focus on kernel artifacts and suspicious local triggering patterns rather than external network indicators.

• WARNING: drivers/dma-buf/dma-resv.c:296
• dma_resv_add_fence
• dma_resv_assert_held
• virtio_gpu_array_add_fence
• virtio_gpu_queue_ctrl_sgs
• virtio_gpu_queue_fenced_ctrl_buffer
• virtio_gpu_cursor_plane_update
• virtio_gpu_resource_flush
• drm_atomic_helper_commit_planes
• drm_atomic_helper_update_plane
• __setplane_atomic
• drm_mode_cursor_universal
• drm_mode_cursor_common
• drm_mode_cursor_ioctl
• DRM_IOCTL_MODE_CURSOR
• virtio_gpu_array_lock_resv
• dma_resv_lock_interruptible
• dma_resv_reserve_fences
• fail_nth
• /dev/dri/card
• /dev/dri/renderD

What your security team should do

• Inventory Linux systems and VM images that use virtio-gpu or expose DRM devices to local users, containers, desktop sessions, or sandboxed workloads.
• Prioritize patching multi-user systems, virtual desktop infrastructure, cloud guests, lab hosts, and CI workers where untrusted users can access /dev/dri/card* or /dev/dri/renderD*.
• Track vendor kernel advisories and deploy the first fixed kernel made available for each supported distribution or appliance platform.
• Where immediate patching is not possible, restrict local access to DRM devices, remove untrusted users from video/render groups, and avoid passing virtio-gpu devices into untrusted containers or guests.
• Monitor kernel logs for dma_resv_add_fence, dma_resv_assert_held, virtio_gpu_cursor_plane_update, and DRM_IOCTL_MODE_CURSOR-related warnings or crashes.
• Treat unexpected kernel WARN/Oops/panic events in virtio-gpu or dma-buf code as potential exploitation attempts on exposed multi-user systems.
• Because this is not currently listed in CISA KEV and has low EPSS, balance urgency against exposure: patch routinely for single-user trusted desktops, but accelerate for shared or hostile local-execution environments.