CVE-2026-99242 in Linux
Summary
by MITRE • 11/02/2026
In the Linux kernel, the following vulnerability has been resolved:
ntfs: fix race between fallocate and mmap reads
The fallocate implementation only takes invalidate_lock for punch hole, collapse range, and insert range operations. For standard allocation modes (mode == 0, FALLOC_FL_KEEP_SIZE), the lock is not held.
During ntfs_attr_fallocate(), new clusters are mapped to the runlist via ntfs_attr_map_cluster() before being zeroed by ntfs_dio_zero_range(). This creates a window where concurrent mmap page faults can read uninitialized disk data.
Since mmap uses filemap_fault() which takes invalidate_lock in shared mode, it can fault in pages during this window and expose old disk contents to userspace. This is an information leak and data integrity issue.
Fix by taking invalidate_lock for all fallocate operations, not just for punch/collapse/insert modes. This prevents concurrent page faults from accessing unzeroed clusters during the allocation window.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/03/2026
The Linux kernel's NTFS filesystem driver contains a concurrency flaw within its file allocation logic that allows for an information leak and data integrity violation. The vulnerability stems from inconsistent locking strategies employed by the fallocate system call implementation. Specifically, the code only acquires the invalidate_lock when performing punch hole, collapse range, or insert range operations. However, for standard allocation modes where no specific flags are set to modify existing extents beyond simple extension, such as mode zero with FALLOC_FL_KEEP_SIZE, this critical lock is not held during the initial phases of cluster mapping and initialization. This oversight creates a race condition window that can be exploited by concurrent memory-mapped input/output operations.
The technical mechanism of exploitation involves the sequence of events within ntfs_attr_fallocate(). When new clusters are allocated for a file, they are first mapped to the runlist via ntfs_attr_map_cluster() before being zeroed out by ntfs_dio_zero_range(). This ordering is standard practice to ensure that space is reserved and tracked correctly. However, because the invalidate_lock is not held during this mapping phase in standard allocation modes, there exists a temporal gap where the clusters are mapped but contain uninitialized data from previous disk usage. During this window, if another process has memory-mapped the same file using mmap(), it can trigger page faults via filemap_fault(). The filemap_fault function acquires the invalidate_lock in shared mode, which is compatible with the write lock held during other operations but does not block access to pages that are currently being modified or mapped without proper synchronization.
Consequently, a concurrent thread performing an mmap read operation may successfully fault in these newly allocated clusters before they have been zeroed by ntfs_dio_zero_range(). This results in the exposure of old disk contents to userspace applications accessing the file through memory mapping. The impact is twofold: it constitutes an information leak where sensitive data from previously deleted or overwritten files can be read, and it represents a data integrity issue as the application receives stale or corrupted data rather than the expected zero-filled blocks. This behavior violates the expectation that newly allocated space in a file should not contain remnants of prior data usage, potentially leading to security breaches if confidential information is present on those disk sectors.
The resolution involves modifying the locking strategy within ntfs_attr_fallocate() to ensure that invalidate_lock is acquired for all fallocate operations, regardless of whether they involve punch hole, collapse range, insert range, or standard allocation modes. By holding this lock throughout the entire duration of cluster mapping and zeroing, the kernel prevents concurrent page faults from accessing unzeroed clusters during the critical allocation window. This change ensures that mmap reads are properly synchronized with file modification operations, thereby eliminating the race condition. The fix aligns with industry best practices for handling concurrency in filesystem drivers, specifically addressing CWE-200 which covers exposure of sensitive information to unauthorized actors and CWE-367 related to time-of-check-time-of-use (TOCTOU) race conditions that allow access to resources before they are properly secured or initialized.
From a defensive perspective, this vulnerability highlights the importance of comprehensive locking coverage in kernel subsystems handling file I/O operations. Security analysts should verify that all code paths within fallocate implementations consistently apply necessary synchronization primitives to prevent partial state exposure. Mitigation strategies include applying the upstream kernel patch that enforces consistent invalidation lock usage across all allocation modes. Additionally, system administrators and developers relying on NTFS filesystems in Linux environments should ensure their kernels are updated to versions containing this fix. Monitoring for unusual memory access patterns or data anomalies in files undergoing frequent reallocation can also serve as a heuristic indicator of exploitation attempts, although the primary defense remains timely patching of the kernel source code to close the synchronization gap identified by ntfs_dio_zero_range and related functions.