CVE-2026-64098

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/virtio: use uninterruptible resv lock for plane updates<br /> <br /> virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock<br /> the framebuffer BO&amp;#39;s dma_resv via virtio_gpu_array_lock_resv() and<br /> ignore its return value. The function can fail with -EINTR from<br /> dma_resv_lock_interruptible() (signal during lock wait) or with<br /> -ENOMEM from dma_resv_reserve_fences() (fence slot allocation),<br /> leaving the resv lock not held. The queue path then walks the object<br /> array and calls dma_resv_add_fence(), which requires the lock held;<br /> with lockdep enabled this trips dma_resv_assert_held():<br /> <br /> WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0x840<br /> Call Trace:<br /> virtio_gpu_array_add_fence<br /> virtio_gpu_queue_ctrl_sgs<br /> virtio_gpu_queue_fenced_ctrl_buffer<br /> virtio_gpu_cursor_plane_update<br /> drm_atomic_helper_commit_planes<br /> drm_atomic_helper_commit_tail<br /> commit_tail<br /> drm_atomic_helper_commit<br /> drm_atomic_commit<br /> drm_atomic_helper_update_plane<br /> __setplane_atomic<br /> drm_mode_cursor_universal<br /> drm_mode_cursor_common<br /> drm_mode_cursor_ioctl<br /> drm_ioctl<br /> __x64_sys_ioctl<br /> <br /> Beyond the WARN, mutating the dma_resv fence list without the lock<br /> races with concurrent readers/writers and can corrupt the list.<br /> <br /> Both call sites run inside the .atomic_update plane callback, which<br /> DRM atomic helpers do not allow to fail (by the time it runs, the<br /> commit has been signed off to userspace and there is no clean<br /> rollback path). Moving the lock acquisition to .prepare_fb was<br /> rejected because the broader lock scope deadlocks against other BO<br /> locking paths in the same atomic commit.<br /> <br /> Introduce virtio_gpu_lock_one_resv_uninterruptible() that uses<br /> dma_resv_lock() instead of dma_resv_lock_interruptible(). This<br /> eliminates the -EINTR failure mode -- the realistic syzbot trigger<br /> -- without extending the lock hold across the commit. The helper<br /> locks a single BO and rejects nents &gt; 1 with -EINVAL; both fix<br /> sites lock exactly one BO.<br /> <br /> Use it from virtio_gpu_cursor_plane_update() and<br /> virtio_gpu_resource_flush(); check the return value to handle the<br /> remaining -ENOMEM case from dma_resv_reserve_fences() by freeing<br /> the objs and skipping the plane update for that frame. The<br /> framebuffer BOs touched here are not shared with other contexts<br /> and lock contention is expected to be brief, so the loss of<br /> signal-interruptibility is acceptable.<br /> <br /> Other callers of virtio_gpu_array_lock_resv() (the ioctl paths)<br /> continue to use the interruptible variant.<br /> <br /> The bug was reported by syzbot, triggered via fault injection<br /> (fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the<br /> -ENOMEM branch in dma_resv_reserve_fences().