CVE-2026-72103 in Linux
Résumé
par VulDB • 17/08/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
dm : éviter de fuir l'anneau de clés du fil d'exécution (thread keyring) de l'appelant via le fichier device table.
Le refactoring effectué dans le commit a28d893eb327 (« md: port block device access to file ») a accidentellement pour effet de maintenir vivant l'anneau de clés du fil d'exécution (thread keyring) de l'appelant bien au-delà de la durée de vie de ce dernier.
En conséquence, « cryptsetup luksSuspend » échoue silencieusement à effacer la clé du volume LUKS de la mémoire.
Plus précisément : « cryptsetup luksOpen » utilise son anneau de clés de fil d'exécution (thread keyring) censé être éphémère pour transmettre la clé du volume au noyau. La fonction `crypt_set_keyring_key()` de dm-crypt copie les données de la clé dans sa propre structure `crypt_config`, puis supprime sa propre référence à la clé dans l'anneau de clés via `key_put()`.
Avec cette correction, qui restaure le comportement d'avant la version 6.9, la copie présente dans l'anneau de clés du fil d'exécution (thread keyring) est ensuite rapidement collectée par le ramasse-miettes (garbage collected), de sorte qu'une seule copie de la clé du volume subsiste. Cette unique copie est correctement effacée de la mémoire lors de « cryptsetup luksSuspend ».
Sans cette correction, l'anneau de clés du fil d'exécution et la clé du volume qu'il contient persistent. Ce second exemplaire n'est libéré que lors de « luksClose ». « luksSuspend » ne connaît pas cet exemplaire ni ne dispose d'un moyen pour le supprimer ; par conséquent, la clé reste récupérable depuis la RAM après une suspension (suspend) qui est documentée comme ayant effacé cette dernière.
Cette correction ne devrait pas introduire de nouveaux problèmes de sécurité, car le code est déjà protégé par CAP_SYS_ADMIN. Le noyau du device-mapper, et non la tâche appelante, est le propriétaire légitime de ce fichier à longue durée de vie.
If you want to get best quality of vulnerability data, you may have to visit VulDB.