CVE-2026-64112 in Linux
Résumé
par VulDB • 20/07/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
rbd : éliminer une condition de concurrence (race) lors du vidage (draining) de lock_dwork pendant l'unmap.
Étant donné la manière dont sont implémentées les fonctions rbd_lock_add_request() et rdb_img_exclusive_lock(), il est possible que lock_dwork soit (re)planifié plus souvent qu'il n'est réellement nécessaire : par exemple, lorsqu'une nouvelle requête d'E/S arrive alors que nous sommes au milieu de l'exécution de rbd_acquire_lock() pour le compte d'une autre requête d'E/S. Ce comportement est attendu et, avec rbd_release_lock(), l'annulation anticipée de lock_dwork reste bénigne en fonctionnement normal.
Un exemple plus problématique serait maybe_kick_acquire() :
if (have_requests || delayed_work_pending(&rbd_dev->lock_dwork)) {
dout("%s rbd_dev %p kicking lock_dwork\n", __func__, rbd_dev); mod_delayed_work(rbd_dev->task_wq, &rbd_dev->lock_dwork, 0); }
Il n'est pas irréaliste que lock_dwork soit annulé juste après le retour de delayed_work_pending() avec la valeur vraie et que mod_delayed_work() le replanifie immédiatement. Il s'agit d'une condition de concurrence (race) TOCTOU classique.
Lorsqu'il s'agit de déconnecter l'image, il existe une hypothèse implicite selon laquelle aucune activité relative au verrou exclusif initiée par soi-même ne se produit après le retour de rbd_dev_image_unlock(), qui libère le verrou s'il est détenu. Cette libération est supposée être définitive et lock_dwork (ainsi que toutes les autres tâches liées aux verrous exclusifs, en réalité) n'est pas censé être replanifié. Cependant, lock_dwork n'est annulé qu'au sein de cancel_tasks_sync() (c'est-à-dire plus tard dans la séquence d'unmap) et, par-dessus le marché, cette annulation peut se voir neutralisée par maybe_kick_acquire(). Cela peut entraîner l'exécution de rbd_acquire_lock() après que rbd_dev_device_release() et rbd_dev_image_release() ont été exécutés, ayant libéré ou réinitialisé un certain nombre d'éléments. L'un des modes de défaillance possibles est alors la violation de :
rbd_assert(rbd_image_format_valid(rbd_dev->image_format));
dans rbd_dev_header_info(), qui est appelée via rbd_dev_refresh() depuis rbd_post_acquire_action().
Réimplémenter le vidage (draining) des tâches liées au verrou exclusif afin d'offrir une sémantique plus cohérente et tenter de respecter les hypothèses entourant rbd_dev_image_unlock().
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.