CVE-2026-98843 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
netfs: zero gaps in read-gaps folio to avoid writing back stale data
netfs_read_gaps() leaves gaps around a streaming write's dirty region unread on the server side, so a short/EOF response there left stale folio content that later got written back.
Zero it after the read completes, not before: netfs_wait_for_read() returns rreq->transferred once ret >= 0, so build an iterator over the same bvec array the read used, advance past ret, and zero the rest. The dirty region already maps to sink pages in that array rather than the real folio, so this can't touch it, and only the actual shortfall gets zeroed instead of the whole gap upfront.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The Linux kernel's network filesystem subsystem contains a critical data integrity vulnerability within the netfs_read_gaps function, which is responsible for handling read operations that involve gaps in file regions. This flaw arises from an incorrect sequence of memory initialization relative to server responses during streaming write scenarios. When a client initiates a read operation across a range that includes both dirty and clean pages, the kernel attempts to fetch data from the remote server for the clean portions while leaving the dirty regions untouched as they are already present in local memory. However, if the server returns a short response or an end-of-file condition before all requested gaps have been filled, the remaining unfilled portions of the folio retain their previous contents rather than being initialized to zero. This behavior creates a scenario where stale data from prior operations remains in memory and is subsequently written back to storage under certain conditions, leading to potential corruption of file content that should logically be empty or null-filled beyond the actual end-of-file boundary.
The technical root cause lies in the timing of when zeroing occurs relative to the completion of the read request. Previously, gaps were potentially zeroed before the read operation completed, which could inadvertently overwrite valid data if the server returned more bytes than expected or if race conditions occurred during concurrent access. The resolution involves deferring the zeroing process until after netfs_wait_for_read confirms that the transfer has concluded successfully by returning rreq->transferred when ret is greater than or equal to zero. By constructing an iterator over the same bio vector array used for the read operation, advancing past the number of bytes actually transferred, and then explicitly zeroing only the remaining portion of the buffer, the kernel ensures that only truly unfilled regions are cleared. This approach preserves data integrity because the dirty region maps to sink pages in the buffer vector rather than the real folio, meaning it is isolated from this zeroing operation and remains unaffected by the fix logic.
From a security perspective, this vulnerability represents a significant risk related to information disclosure and data corruption. An attacker with local access who can trigger specific read patterns on network filesystems might exploit this flaw to observe stale kernel memory contents that were not properly cleared after incomplete reads. This aligns with CWE-200, which covers exposure of sensitive information through error conditions or improper cleanup, as well as CWE-665 regarding improper initialization of data structures. The failure to zero out unused portions of a folio allows residual data from previous allocations to persist in memory pages that are later written back to disk, potentially leaking private keys, passwords, or other confidential material stored in those regions during prior usage cycles.
The operational impact extends beyond mere information leakage to include severe file system corruption and application instability. Applications relying on the assumption that read operations return zero-filled buffers for gaps may instead receive unpredictable data from previous allocations, leading to logic errors, crashes, or silent data degradation. In distributed storage environments where consistency is paramount, such discrepancies can cause replication failures or inconsistent views of files across multiple nodes. The vulnerability affects systems using network filesystems like NFS, CephFS, or any other implementation relying on the netfs infrastructure for handling sparse reads and streaming writes, making it a widespread concern for enterprise deployments dependent on these storage protocols.
Mitigation strategies primarily involve applying the kernel patch that corrects the zeroing logic within netfs_read_gaps to ensure it occurs post-transfer verification rather than pre-read initialization. Administrators should prioritize updating their Linux kernels to versions where this fix is included, particularly those running network filesystem clients in production environments. Additionally, implementing strict access controls and monitoring for unusual read patterns can help detect potential exploitation attempts while patching efforts are underway. Regular auditing of file system integrity using tools like fsck or specialized data validation scripts can also identify any corruption resulting from past instances of this vulnerability before it causes catastrophic failures in critical applications relying on accurate file contents.