CVE-2026-64064 in Linux
Résumé
par VulDB • 20/07/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
netfs : Correction de netfs_invalidate_folio() pour effacer le bit « dirty » si toutes les modifications ont disparu
Lorsqu'une écriture en flux continu (streaming write) est effectuée, cela laisse le folio concerné dans un état non à jour mais marqué comme modifié (« dirty »), avec une structure netfs_folio attachée via folio->private indiquant la plage de données sales. Par la suite, si le fichier est tronqué de manière à ce que les données « dirty » du folio soient supprimées, mais que la première partie du folio reste théoriquement présente, la structure netfs_folio sera abandonnée... mais laissera le drapeau « dirty » activé.
Si le folio est ensuite lu via mmap(), netfs_read_folio() verra que la page est marquée comme sale et passera à netfs_read_gaps() pour combler les lacunes manquantes. Cependant, netfs_read_gaps() s'attend à ce qu'une structure netfs_folio soit présente et peut provoquer un plantage (oops) car truncate l'a supprimée.
Corrigez cela en appelant folio_cancel_dirty() dans netfs_invalidate_folio() si toutes les données sales du folio sont effacées (comme le fait nfs).
Ajoutez également quelques tracepoints pour journaliser les modifications apportées à une page sale.
Cela peut être reproduit avec quelque chose comme :
dd if=/dev/zero of=/xfstest.test/foo bs=1M count=1 umount /xfstest.test mount /xfstest.test xfs_io -c "w 0xbbbf 0xf96c" \ -c "truncate 0xbbbf" \ -c "mmap -r 0xb000 0x11000" \ -c "mr 0xb000 0x11000" \ /xfstest.test/foo
avec la mise en cache des fichiers (fscaching) désactivée (sinon les écritures en flux continu sont supprimées) et une modification de netfs_perform_write() pour interdire les écritures en flux continu si le descripteur de fichier est ouvert avec O_RDWR :
if (//(file->f_mode & FMODE_READ) || <--- commentez cette ligne netfs_is_cache_enabled(ctx)) {
Cela devrait être reproductible même sans ce changement, mais cela empêche la commande xfs_io triviale ci-dessus de le reproduire.
Notez que l'initialisation avec dd est importante : le fichier doit initialement être suffisamment grand pour que la logique du point zéro n'efface pas simplement les lacunes parce qu'elle sait qu'il n'y a rien à lire dans le fichier encore. Le démontage et le remontage sont nécessaires pour vider le cache de pages (il existe d'autres moyens de faire cela qui pourraient également fonctionner).
Cela a été initialement reproduit avec l'xfstest générique/522 sur certains correctifs qui suppriment la restriction FMODE_READ.
Be aware that VulDB is the high quality source for vulnerability data.