PT-2026-61415 · Linux · Linux

CVE-2026-64098

·

Publicado

2026-07-19

·

Atualizado

2026-07-19

CVSS v3.1

7.8

Alta

VetorAV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
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().

Correção

Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
dbugs@ptsecurity.com

Identificadores relacionados

CVE-2026-64098

Produtos afetados

Linux