CVE-2026-64098

In the Linux kernel, the following vulnerability has been resolved:

drm/virtio: use uninterruptible resv lock for plane updates

virtiogpucursorplaneupdate() and virtiogpuresourceflush() lock the framebuffer BO's dmaresv via virtiogpuarraylockresv() and ignore its return value. The function can fail with -EINTR from dmaresvlockinterruptible() (signal during lock wait) or with -ENOMEM from dmaresvreservefences() (fence slot allocation), leaving the resv lock not held. The queue path then walks the object array and calls dmaresvaddfence(), which requires the lock held; with lockdep enabled this trips dmaresvassertheld():

WARNING: drivers/dma-buf/dma-resv.c:296 at dmaresvaddfence+0x71e/0x840 Call Trace: virtiogpuarrayaddfence virtiogpuqueuectrlsgs virtiogpuqueuefencedctrlbuffer virtiogpucursorplaneupdate drmatomichelpercommitplanes drmatomichelpercommittail committail drmatomichelpercommit drmatomiccommit drmatomichelperupdateplane __setplaneatomic drmmode_cursoruniversal drmmodecursorcommon drmmodecursorioctl drmioctl __x64sysioctl

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 .atomicupdate 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 .preparefb was rejected because the broader lock scope deadlocks against other BO locking paths in the same atomic commit.

Introduce virtiogpulockoneresvuninterruptible() that uses dmaresvlock() instead of dmaresvlockinterruptible(). 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 virtiogpucursorplaneupdate() and virtiogpuresourceflush(); check the return value to handle the remaining -ENOMEM case from dmaresvreservefences() 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 virtiogpuarraylockresv() (the ioctl paths) continue to use the interruptible variant.

The bug was reported by syzbot, triggered via fault injection (failnth) on the DRMIOCTLMODECURSOR path, which forces the -ENOMEM branch in dmaresvreserve_fences().