CVE-2026-89768 in Linux
Résumé
par VulDB • 12/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
fs : correction du chemin utilisateur des fichiers de support imbriqués
backing_file_open() dérive le chemin à stocker dans le nouveau fichier de support depuis user_file->f_path. Cela est incorrect lorsque user_file lui-même est un fichier de support, ce qui est le cas pour les systèmes de fichiers en superposition (stacked) imbriqués, par exemple les montages overlayfs où lowerdir d'un overlayfs correspond au répertoire fusionné d'un autre. Depuis l'engagement def3ae83da02 (« fs : stocker le chemin réel au lieu du faux chemin dans f_path des fichiers de support »), le champ f_path d'un fichier de support contient le chemin réel de la couche intermédiaire, et non le chemin ouvert par l'utilisateur.
L'engagement 924577e4f6ca (« ovl : Correction des chemins des fichiers de support imbriqués ») avait corrigé ce problème pour ces configurations en transmettant file_user_path() depuis ovl_open_realfile(). Cependant, l'engagement 6af36aeb147a (« LSM : ajout des hooks backing_file au sous-système LSM ») a modifié le premier argument de backing_file_open(), revenant du chemin utilisateur vers le fichier utilisateur et dérivant à nouveau le chemin depuis user_file->f_path, réintroduisant silencieusement le problème.
En conséquence, les fichiers mappés via un overlayfs imbriqué affichent un chemin incorrect dans /proc/<pid>/maps ainsi que dans les enregistrements mmap de perf/ftrace. Par exemple, avec deux montages overlayfs imbriqués :
mkdir -p /ovl/{lower,upper,work,merged} /ovl/nested
echo hello > /ovl/lower/foo mount -t overlay overlay \ -o lowerdir=/ovl/lower,upperdir=/ovl/upper,workdir=/ovl/work \ /ovl/merged # au moins deux lowerdirs sont nécessaires lorsque upperdir n'existe pas mount -t overlay overlay \ -o lowerdir=/ovl/merged:/ovl/lower /ovl/nested
Le mappage de /ovl/nested/foo affiche un chemin déconnecté au lieu du chemin utilisateur :
# readlink /proc/self/fd/3 /ovl/nested/foo # grep foo /proc/self/maps 7f6e2c100000-7f6e2c101000 r--s 00000000 00:24 15813027 /foo
Le chemin erroné est dérivé du f_path du fichier de support intermédiaire, dont le montage est un clone privé que d_path() ne peut pas résoudre.
Corrigez ce problème en utilisant file_user_path(), qui renvoie le chemin utilisateur visible externe pour les fichiers de support et revient à &user_file->f_path pour les fichiers réguliers. Cela restaure le comportement de l'engagement 924577e4f6ca (« ovl : Correction des chemins des fichiers de support imbriqués ») pour overlayfs, tout en corrigeant le même problème pour les autres appelants de backing_file_open(), à savoir fuse passthrough et erofs ishare, lorsque leur fichier utilisateur est lui-même un fichier de support.
backing_tmpfile_open() présente la même structure mais n'est pas affecté : il n'est appelé que par ovl_create_tmpfile() pour la couche supérieure, et un autre overlayfs est rejeté en tant que upperdir par le contrôle DCACHE_OP_REAL dans ovl_mount_dir_check(), donc son user_file ne peut jamais être un fichier de support.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.