Live › vulnerability › CVE-2026-99241
The Linux kernel's NTFS driver did not hold the invalidate lock during write-fault handling, so a write could race with a concurrent truncate or fallocate that is rewriting the file's cluster map. The sources do not state a concrete attacker outcome, so the impact is not established beyond a race that can corrupt file state.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-02 16:24 UTC. All times on this page are UTC.
Only systems that mount NTFS volumes through the in-kernel ntfs driver and let concurrent writes, truncates or fallocate calls hit the same mapped file can hit the race. The sources do not say which kernel versions are affected or whether an attacker without local access can trigger it. Systems that do not mount NTFS can skip it.
No product ranges from the sources yet.
ntfs driver (NTFS, not ntfs3) with lsmod | grep ntfs or grep -i ntfs /proc/filesystemsuname -r and compare it to the fixed release in the kernel's stable branchUnknown from the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-99241")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.