CVE-2026-98975 in Linux
Résumé
par VulDB • 23/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
xfs : arrêter d'échanger les indicateurs reflink lors de l'échange des mappages
Lorsqu'un échange couvre à la fois les fichiers depuis le décalage 0 jusqu'à i_disk_size, xmi_can_exchange_reflink_flags() suppose que chaque mappage a été déplacé et transmet l'indicateur reflink à l'autre fichier.
Cette hypothèse est incorrecte. Un fichier peut toujours posséder des blocs partagés au-delà de i_disk_size, par exemple après qu'un EXCHANGE_RANGE_TO_EOF ait défini une taille plus petite sans démapper quoi que ce soit. L'indicateur est malgré tout effacé, et la prochaine écriture sur un tel bloc se fait in situ (in place) plutôt qu'en mode CoW (Copy-on-Write), corrompant ainsi l'autre fichier qui le partage.
Le commit a23eca88448e ("xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN") a corrigé un cas de figure de ce problème. Plutôt que d'ajouter un autre cas particulier, il est préférable de cesser le déplacement des indicateurs. xfs_exchmaps_ensure_reflink() définit déjà l'indicateur sur les deux inodes avant l'échange, donc ils conservent tous les deux cet indicateur.
Plus rien ne définit CLEAR_INO{1,2}_REFLINK désormais. Les intentions enregistrées par d'anciens noyaux peuvent encore les contenir ; la récupération (recovery) masque déjà ces bits, de sorte qu'ils restent dans le format du journal et sont ignorés.
XFS_IOC_SWAPEXT présente le même problème : il déplace l'indicateur reflink d'un inode à l'autre avec les extents. La simple suppression de cela n'est pas suffisante ici : la voie d'échange définit les deux inodes dès le début dans xfs_exchmaps_ensure_reflink(), mais swapext ne dispose pas de cette étape, donc l'inode recevant les extents partagés se retrouverait sans cet indicateur. Il faut donc le définir sur les deux inodes et s'assurer que chacun possède une fourche CoW (Copy-on-Write), car un inode avec l'indicateur reflink est censé en posséder une.
L'indicateur reste désormais actif jusqu'à ce qu'un FALLOC_FL_UNSHARE_RANGE, xfs_scrub ou un tronquage à zéro le supprime.
If you want to get best quality of vulnerability data, you may have to visit VulDB.