CVE-2026-64098 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: use uninterruptible resv lock for plane updates
virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock the framebuffer BO's dma_resv via virtio_gpu_array_lock_resv() and ignore its return value. The function can fail with -EINTR from dma_resv_lock_interruptible() (signal during lock wait) or with -ENOMEM from dma_resv_reserve_fences() (fence slot allocation), leaving the resv lock not held. The queue path then walks the object array and calls dma_resv_add_fence(), which requires the lock held; with lockdep enabled this trips dma_resv_assert_held():
WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0x840 Call Trace: virtio_gpu_array_add_fence virtio_gpu_queue_ctrl_sgs virtio_gpu_queue_fenced_ctrl_buffer virtio_gpu_cursor_plane_update drm_atomic_helper_commit_planes drm_atomic_helper_commit_tail commit_tail drm_atomic_helper_commit drm_atomic_commit drm_atomic_helper_update_plane __setplane_atomic drm_mode_cursor_universal drm_mode_cursor_common drm_mode_cursor_ioctl drm_ioctl __x64_sys_ioctl
Beyond the WARN, mutating the dma_resv fence list without the lock races with concurrent readers/writers and can corrupt the list.
Both call sites run inside the .atomic_update plane callback, which DRM atomic helpers do not allow to fail (by the time it runs, the commit has been signed off to userspace and there is no clean rollback path). Moving the lock acquisition to .prepare_fb was rejected because the broader lock scope deadlocks against other BO locking paths in the same atomic commit.
Introduce virtio_gpu_lock_one_resv_uninterruptible() that uses dma_resv_lock() instead of dma_resv_lock_interruptible(). This eliminates the -EINTR failure mode -- the realistic syzbot trigger -- without extending the lock hold across the commit. The helper locks a single BO and rejects nents > 1 with -EINVAL; both fix sites lock exactly one BO.
Use it from virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush(); check the return value to handle the remaining -ENOMEM case from dma_resv_reserve_fences() by freeing the objs and skipping the plane update for that frame. The framebuffer BOs touched here are not shared with other contexts and lock contention is expected to be brief, so the loss of signal-interruptibility is acceptable.
Other callers of virtio_gpu_array_lock_resv() (the ioctl paths) continue to use the interruptible variant.
The bug was reported by syzbot, triggered via fault injection (fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the -ENOMEM branch in dma_resv_reserve_fences().
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/19/2026
This vulnerability exists within the linux kernel's virtio graphics driver component, specifically affecting the drm/virtio subsystem where improper lock handling can lead to system instability and potential security implications. The issue stems from how framebuffer object reservation locks are managed during cursor plane updates and resource flushing operations. When these functions attempt to acquire locks on dma_resv objects through virtio_gpu_array_lock_resv(), they fail to properly handle error conditions that can occur during the locking process, particularly when signals interrupt lock waits or when memory allocation fails for fence slots. This improper error handling creates a scenario where the reservation lock is not actually held, yet subsequent operations attempt to manipulate the fence list without proper synchronization, leading to race conditions and potential data corruption within the dma-resv subsystem.
The technical flaw manifests in two specific functions: virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush(), both of which use the interruptible locking variant that can return -EINTR when signals are received during lock acquisition or -ENOMEM when fence slot allocation fails. These error conditions are ignored, allowing execution to proceed without proper lock acquisition. The subsequent calls to dma_resv_add_fence() require the reservation lock to be held, but since it's not actually acquired, this triggers kernel lockdep assertions and creates race conditions between concurrent readers and writers of the fence list structure. This type of vulnerability aligns with CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and CWE-129 (Improper Validation of Array Index) as it involves improper locking mechanisms and potential memory corruption through unsynchronized access patterns.
The operational impact of this vulnerability is significant within graphics driver contexts where atomic updates must maintain consistency and prevent data races. Since these functions operate during the .atomic_update plane callback phase, they execute after commit signing off to userspace, meaning there's no clean rollback mechanism if errors occur. The lockdep warning indicates a direct violation of locking assumptions in the dma-resv subsystem, which could lead to memory corruption that might be exploitable for privilege escalation or system instability. The vulnerability was identified through syzbot's fault injection testing targeting the DRM_IOCTL_MODE_CURSOR path, where specific -ENOMEM conditions in fence slot allocation were forced to trigger the problematic code path.
The solution implemented involves introducing a new helper function virtio_gpu_lock_one_resv_uninterruptible() that uses dma_resv_lock() instead of the interruptible variant, eliminating the -EINTR failure mode while maintaining appropriate lock scope. This approach addresses the core issue by ensuring locks are properly acquired before fence list manipulations, preventing the race conditions that could lead to data corruption. The implementation specifically rejects multiple BO operations with -EINVAL and handles the remaining -ENOMEM case by cleaning up allocated objects and skipping the plane update for that frame, which is acceptable given that these framebuffer objects are not shared across contexts and lock contention is expected to be brief. This fix aligns with ATT&CK technique T1068 (Exploitation for Privilege Escalation) by preventing potential attack vectors through memory corruption, and with MITRE ATT&CK tactic TA0004 (Privilege Escalation) as the vulnerability could enable escalation through system instability.
The proposed mitigation strategy maintains backward compatibility for other code paths that legitimately require interruptible locking behavior during ioctl operations, ensuring that only the specific problematic functions are modified to use uninterruptible locks. This selective approach prevents broader system impacts while addressing the core synchronization issue, and the solution preserves the intended lock scope limitations by avoiding extended lock holding periods that could cause deadlocks in other parts of the atomic commit process. The fix ensures proper error handling for all failure modes while maintaining system stability through careful resource management and appropriate error propagation to prevent partial updates that could leave the graphics subsystem in an inconsistent state.