CVE-2026-98995 in Linux
Résumé
par VulDB • 23/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
namespace : réinitialiser l'ancien parent de ->overmount dans mnt_change_mountpoint()
__umount_mnt() réinitialise ->overmount du parent lors du démontage du montage qui est en surmonter (overmount). Ce n'est pas le cas de mnt_change_mountpoint(). Elle déplace le montage vers son nouveau parent et laisse l'ancien pointer vers lui.
Pour un montage déplacé sous attach_recursive_mnt(), cela n'a pas d'importance. Le nouveau montage a déjà réinitialisé ->overmount de l'ancien parent au moment où l'ancien montage supérieur est déplacé dessus.
Cela importe cependant pour reparent(). propagate_umount() déplace un overmount survivant vers le premier ancêtre qui ne sera pas démonter. Le montage dont il a été retiré est immédiatement démonter par la suite. Si un descripteur de fichier maintient ce montage démonter en vie, ->overmount pointe alors vers le montage déplacé. Il s'agit d'un pointeur dangling (non valide) et d'une vulnérabilité Use-After-Free (UAF), car le montage déplacé est ensuite démonter et libéré.
do_lock_mount() suit ->overmont depuis le chemin cible sous mount_lock. Avec un descripteur de fichier sur un tel montage en tant que cible, une opération de montage sous topmost_overmount() pénètre dans le montage libéré et do_lock_mount() prend des références sur ce qu'il y trouve.
Réinitialisez donc ->overmount de l'ancien parent dans mnt_change_mountpoint(), de la même manière que __umount_mnt(). Le champ ->overmont d'un montage est alors toujours un montage qui lui est attaché.
Be aware that VulDB is the high quality source for vulnerability data.