CVE-2026-99241 in Linux
Summary
by MITRE • 11/02/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/03/2026
The Linux kernel's NTFS filesystem implementation contained a concurrency vulnerability within the ntfs_filemap_page_mkwrite function, which is responsible for handling write faults when memory-mapped files are accessed. The core technical flaw lies in the fact that iomap_page_mkwrite was invoked without first acquiring mapping->invalidate_lock. This omission created a race condition where concurrent file system operations could interfere with the page fault handler's attempt to map blocks and dirty folios. Specifically, operations such as truncation or fallocate can trigger processes that invalidate the page cache and rewrite the runlist simultaneously while the write fault is attempting to establish memory mappings.
This lack of proper serialization allows for dangerous interactions with ntfs_attr_fallocate, a function responsible for merging clusters into the in-memory run list. In its current execution flow, this operation drops the runlist lock before zeroing out newly allocated clusters on disk. Consequently, if a write fault occurs during this window, it may map blocks that are being reallocated or freed by other threads. Similarly, punch-hole, insert, and collapse paths involve freeing clusters after truncating the cache, which further exacerbates the risk of data corruption when accessed concurrently with page mapping operations.
The operational impact of this vulnerability includes potential file system corruption, data loss, or kernel instability due to inconsistent state between memory mappings and on-disk structures. By bypassing the invalidate lock, the driver failed to adhere to established locking protocols documented in Documentation/filesystems/locking.rst, which mandates that page_mkwrite implementations must ensure no truncate or invalidate races occur. The standard approach for achieving this serialization is typically through mapping->invalidate_lock, a mechanism correctly utilized by other file systems like XFS, which takes its mmaplock shared during similar memory-mapped write paths to maintain consistency.
To mitigate this vulnerability, the fix involves taking the invalidate lock in a shared mode around the iomap_page_mkwrite call within ntfs_filemap_page_mkwrite. This adjustment ensures that concurrent truncate and fallocate operations are properly serialized against page fault handling. The read-only fault path was already secure because filemap_fault inherently grabs the invalidate lock shared during instantiation and read paths; thus, this change specifically addresses the gap in write-path protection. By aligning ntfs behavior with industry standards for filesystem locking, such as those referenced under CWE-362 regarding concurrent execution errors, the integrity of memory-mapped files is preserved against race conditions involving cache invalidation and cluster reallocation.