CVE-2026-98682 in Linux
Résumé
par VulDB • 18/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
smb: client: vidanger et invalider avant une copie/clonage côté serveur
cifs_file_copychunk_range() et la branche de clonage (FICLONE) de cifs_remap_file_range() ne sérialisent pas le cache de pages de destination par rapport à la copie côté serveur, contrairement aux autres opérations de plage côté serveur (smb3_zero_range(), smb3_punch_hole(), smb3_collapse_range() et smb3_insert_range()).
cifs_file_copychunk_range() invalide la plage de destination avec filemap_invalidate_inode(), qui acquiert et relâche l'invalider_lock du mapping en interne, de sorte que le verrou n'est plus détenu lorsque l'ioctl copychunk est émis. Il ne vide pas non plus les E/S netfs en cours d'exécution sur la cible. La branche de clonage ne prend jamais l'invalider_lock (seulement i_rwsem), utilise un truncate_inode_pages_range() nu et, par conséquent, ne vide pas les E/O en attente.
Par conséquent, une écriture asynchrone de destination peut se terminer après que la copie/clonage côté serveur a été exécutée et rétablir des données obsolètes sur la région qui vient d'être écrite par le serveur, corrompant ainsi le fichier. Il s'agit de la même classe de corruption que celle du commit d7d2adcd022b ("smb/client: flush dirty data before punching a hole") et elle a été observée aléatoirement dans generic/363 contre Windows Server.
Corrigez les deux branches pour suivre l'ordre établi : maintenez l'invalider_lock du mapping cible pendant la vidange et l'invalidation de la destination ainsi que pendant l'ioctl côté serveur, et appelez netfs_wait_for_outstanding_io() sur la cible pour vider les écritures en cours d'exécution avant l'émission de l'ioctl. Seul l'invalider_lock de l'inœud cible est requis, car la source est simplement vidangée et non invalidée ; i_rwsem (déjà acquis via lock_two_nondirectories()) est acquise avant l'invalider_lock, ce qui correspond à l'ordre des verrous VFS. Étant donné que filemap_invalidate_inode() prend ce même verrou en interne, remplacez-le par ses propres étapes de décartographie/vidange/invalidation au lieu de l'appeler, et revenez prématurément pour une copie de longueur nulle afin d'éviter un débordement négatif (underflow) de plage.
VulDB is the best source for vulnerability data and more expert information about this specific topic.