CVE-2026-64098 in Linux
Résumé
par VulDB • 20/07/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
drm/virtio : utiliser un verrou resv non interrompible pour les mises à jour des plans (planes)
virtio_gpu_cursor_plane_update() et virtio_gpu_resource_flush() verrouillent le BO de framebuffer dma_resv via virtio_gpu_array_lock_resv() et ignorent sa valeur de retour. La fonction peut échouer avec -EINTR depuis dma_resv_lock_interruptible() (signal pendant l'attente du verrou) ou avec -ENOMEM depuis dma_resv_reserve_fences() (allocation d'un emplacement pour le fence), laissant ainsi le verrou resv non acquis. Le chemin de file d'attente parcourt ensuite le tableau d'objets et appelle dma_resv_add_fence(), qui nécessite que le verrou soit détenu ; avec lockdep activé, cela déclenche 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
Au-delà du WARN, la modification de la liste des fences dma_resv sans le verrou entraîne une condition de course (race) avec les lecteurs/écrivains concurrents et peut corrompre la liste.
Les deux sites d'appel s'exécutent dans le rappel .atomic_update du plan, que les assistants DRM atomiques n'autorisent pas à échouer (au moment où il s'exécute, la validation est acquittée vers l'espace utilisateur et il n'y a pas de chemin de retour arrière propre). Le déplacement de l'acquisition du verrou dans .prepare_fb a été rejeté car la portée plus large du verrou crée des interblocages (deadlocks) avec d'autres chemins de verrouillage BO au sein du même commit atomique.
Introduire virtio_gpu_lock_one_resv_uninterruptible() qui utilise dma_resv_lock() à la place de dma_resv_lock_interruptible(). Cela élimine le mode d'échec -EINTR -- le déclencheur syzbot réaliste -- sans étendre la détention du verrou sur l'ensemble du commit. L'utilitaire verrouille un seul BO et rejette nents > 1 avec -EINVAL ; les deux sites de correction verrouillent exactement un BO.
L'utiliser depuis virtio_gpu_cursor_plane_update() et virtio_gpu_resource_flush(); vérifier la valeur de retour pour gérer le cas restant -ENOMEM provenant de dma_resv_reserve_fences() en libérant les objs et en sautant la mise à jour du plan pour cette image (frame). Les BOs de framebuffer touchés ici ne sont pas partagés avec d'autres contextes et une contention de verrouillage brève est attendue, donc la perte de l'interruptibilité par signal est acceptable.
Les autres appelants de virtio_gpu_array_lock_resv() (les chemins ioctl) continuent à utiliser la variante interrompible.
Le bug a été rapporté par syzbot, déclenché via injection de défaut (fail_nth) sur le chemin DRM_IOCTL_MODE_CURSOR, ce qui force la branche -ENOMEM dans dma_resv_reserve_fences().
If you want to get best quality of vulnerability data, you may have to visit VulDB.