CVE-2026-99241
Publiée le 2026-11-02 · Dernière modification le 2026-11-02
Le pilote NTFS du noyau Linux, utilisé pour lire et écrire sur des disques formatés pour Windows, contient une condition de concurrence (race condition) dans sa gestion du mappage mémoire. Lors de l'écriture dans un fichier, le pilote ne verrouille pas certaines structures de données, ce qui peut créer un conflit si un autre processus tronque ou modifie simultanément ce même fichier. Cela crée une fenêtre durant laquelle le système peut tenter d'écrire des données sur des blocs de disque en cours de libération ou de réaffectation.
Un attaquant ayant un accès local au système pourrait exploiter cette faille pour provoquer un plantage du noyau (déni de service) ou potentiellement corrompre des fichiers sur le volume NTFS. Comme cela nécessite la capacité de déclencher des opérations de fichiers spécifiques sur une partition NTFS montée, l'attaque ne peut pas être exécutée à distance via un réseau. Il s'agit d'un défaut de synchronisation complexe qui requiert généralement des privilèges d'utilisateur local pour être déclenché.
RÉFÉRENCES
Description officielle du NVD (en anglais)
In the Linux kernel, the following vulnerability has been resolved: ntfs: take invalidate_lock in ntfs_filemap_page_mkwrite() ntfs_filemap_page_mkwrite() calls iomap_page_mkwrite() without holding mapping->invalidate_lock, so a concurrent truncate or fallocate can be in the middle of invalidating pagecache and rewriting the runlist while the write fault maps blocks and dirties the folio. This races with ntfs_attr_fallocate(), which merges clusters into the in-memory runlist, drops the runlist lock, and only afterwards zeroes the newly allocated clusters on disk; and with the punch-hole/insert/collapse paths that free clusters after truncating the cache. Per Documentation/filesystems/locking.rst, ->page_mkwrite() must ensure there are no truncate/invalidate races, "usually mapping->invalidate_lock is suitable for proper serialization". xfs takes its mmaplock (= the invalidate_lock rwsem) shared in exactly this path. Take invalidate_lock shared around iomap_page_mkwrite(). The read-only fault path is already covered because filemap_fault() itself grabs invalidate_lock shared on instantiation/read paths; only page_mkwrite was bypassing it in this driver.