CVE-2026-98844 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
netfs: clear post-EOF pagecache when extending a file via write
Fix netfs to erase the contents of a hole created after the EOF by an ordinary write if dirty data has been previously left there by writes through an mmapped region. Neither the buffered nor the unbuffered/DIO write path clears that stale pagecache.
Zero the tail of the folio straddling the EOF before an extending write. That is the only folio that can hold data written past the EOF through an mmap, as pages wholly beyond the EOF can't be faulted in. The folio is zeroed rather than dropped so a concurrent extending write can't lose data.
Both write paths downgrade the i_rwsem to shared, so extending writes can run concurrently and the i_size read by the caller may be stale by the time the folio is locked. Re-read i_size under the folio lock and clamp the zeroed range up to it, so a racing write that already put data into the folio isn't clobbered.
Wait for any writeback on the folio to finish before zeroing it so that the pagecache isn't modified while it may still be read by the transport during transmission. Honour IOCB_NOWAIT by returning -EAGAIN rather than blocking on the folio lock, on writeback, or in folio_mkclean()'s rmap walk when the folio is mapped.
truncate_pagecache() can't be used here: it must be called with the i_rwsem held exclusively, but these write paths only hold it shared, and it would block unconditionally, breaking IOCB_NOWAIT.
Callers that hold i_rwsem exclusively for the whole resize (truncate, setattr, fallocate, clone) exclude any genuine concurrent buffered writer, so staleness can instead be decided from the folio's dirty state, as pagecache_isize_extended() already does for filesystems that serialise writes against truncate/setattr via a single i_rwsem. Export netfs_clear_stale_post_isize() helper to handle such case.
The helper is required by the CIFS client to fix generic/363.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/18/2026
This vulnerability addresses a critical data integrity issue within the Linux kernel's network filesystem (netfs) subsystem, specifically concerning how file extensions are handled when dirty page cache contents exist beyond the end of file. The core technical flaw lies in the failure to clear stale post-End-of-File pagecache entries that arise from writes performed through memory-mapped regions. When a file is extended via an ordinary write operation, any previously written data that resides past the current file size boundary remains uncleared if it was left there by mmap-based operations. This oversight affects both buffered and unbuffered direct I/O paths, leading to potential exposure of stale or incorrect data when subsequent reads occur after the file has been truncated or extended in a way that exposes these regions.
The operational impact stems from the complex concurrency model used during write operations. Both buffered and direct I/O write paths typically downgrade the inode read-write semaphore to shared mode, allowing multiple extending writes to proceed concurrently. However, this concurrent access creates a race condition where the file size recorded by the caller may become stale before the actual folio is locked for modification. Without proper synchronization, there is a risk that data written by one process could be clobbered or overwritten by another, leading to data corruption. Furthermore, attempting to use standard truncation functions like truncate_pagecache would break non-blocking I/O operations because such functions require exclusive access to the inode semaphore and block unconditionally, which violates the requirements for IOCB_NOWAIT semantics where immediate return of -EAGAIN is necessary if resources are not immediately available.
To resolve this, the fix implements a precise zeroing mechanism for the tail of the folio that straddles the end-of-file boundary. This specific folio is targeted because it is the only one capable of holding data written past EOF through mmap, as pages entirely beyond EOF cannot be faulted in under normal circumstances. The solution involves re-reading the inode size while holding the folio lock to ensure accuracy against racing writes and clamping the zeroed range up to this verified size limit. This approach prevents clobbering data that a concurrent write may have already placed into the folito. Additionally, the implementation ensures that any ongoing writeback on the folio completes before zeroing begins, preventing modification of page cache while it might still be read by network transports during transmission. The code also honors IOCB_NOWAIT flags by returning -EAGAIN rather than blocking on locks or clean-up operations when the folio is mapped.
The remediation strategy distinguishes between concurrent buffered writers and exclusive resize operations such as truncate, setattr, fallocate, and clone. For callers holding the inode semaphore exclusively for the entire duration of a resize operation, genuine concurrent buffered writes are excluded. In these scenarios, staleness can be determined based on the dirty state of the folio, similar to how pagecache_isize_extended handles filesystems that serialize writes against truncation via a single lock. A new helper function, netfs_clear_stale_post_isize, has been exported specifically to handle this exclusive case, ensuring consistency across different network file system implementations. This fix is particularly critical for the CIFS client, where it resolves specific generic test failures related to post-EOF data handling and ensures compliance with expected POSIX semantics regarding file size and content visibility after truncation or extension events.