CVE-2026-64098 in Linux
Zusammenfassung
von VulDB • 20.07.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
drm/virtio: Ununterbrechbares Reservations-Lock (resv lock) für Plane-Aktualisierungen verwenden
virtio_gpu_cursor_plane_update() und virtio_gpu_resource_flush() sperren den dma_resv des Framebuffer-BOs über virtio_gpu_array_lock_resv() und ignorieren dessen Rückgabewert. Die Funktion kann mit -EINTR von dma_resv_lock_interruptible() (Signal während der Wartezeit auf das Lock) oder mit -ENOMEM von dma_resv_reserve_fences() (Zuweisung des Fence-Slots) fehlschlagen, wodurch das resv-Lock nicht gehalten wird. Der Queue-Pfad durchläuft daraufhin das Objekt-Array und ruft dma_resv_add_fence() auf, was erfordert, dass das Lock gehalten ist; bei aktiviertem lockdep löst dies dma_resv_assert_held() aus:
WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0840 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
Neben der WARN-Meldung führt das Ändern der dma_resv-Fence-Liste ohne Lock zu einer Race Condition mit gleichzeitigen Lesern/Schreibern und kann die Liste beschädigen.
Beide Aufrufstellen befinden sich innerhalb des .atomic_update-Plane-Callbacks, den DRM Atomic-Helfer nicht fehlschlagen lassen dürfen (zum Zeitpunkt der Ausführung wurde das Commit an Userspace übergeben und es gibt keinen sauberen Rollback-Pfad). Das Verschieben der Lock-Akquise auf .prepare_fb wurde abgelehnt, da die erweiterte Lock-Scope zu Deadlocks gegen andere BO-Lock-Pfade im selben Atomic-Commit führt.
Es wird virtio_gpu_lock_one_resv_uninterruptible() eingeführt, das dma_resv_lock() anstelle von dma_resv_lock_interruptible() verwendet. Dies eliminiert den -EINTR-Fehlermodus – den realistischen Auslöser für syzbot –, ohne die Lock-Haltedauer über das Commit hinaus zu verlängern. Die Hilfsfunktion sperrt einen einzelnen BO und lehnt nents > 1 mit -EINVAL ab; beide Korrekturstellen sperren genau einen BO.
Verwenden Sie dies aus virtio_gpu_cursor_plane_update() und virtio_gpu_resource_flush(); prüfen Sie den Rückgabewert, um den verbleibenden -ENOMEM-Fall von dma_resv_reserve_fences() zu behandeln, indem die objs freigegeben und die Plane-Aktualisierung für diesen Frame übersprungen wird. Die hier betroffenen Framebuffer-BOs werden nicht mit anderen Kontexten geteilt, und es ist davon auszugehen, dass die Lock-Kontention kurzfristig bleibt, sodass der Verlust der Signalunterbrechbarkeit akzeptabel ist.
Andere Aufrufer von virtio_gpu_array_lock_resv() (die ioctl-Pfade) verwenden weiterhin die unterbrechbare Variante.
Der Bug wurde von syzbot gemeldet und ausgelöst durch Fault Injection (fail_nth) auf dem DRM_IOCTL_MODE_CURSOR-Pfad, der den -ENOMEM-Zweig in dma_resv_reserve_fences() erzwingt.
If you want to get best quality of vulnerability data, you may have to visit VulDB.