CVE-2026-98118 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix readahead synchronisation issues by loading all folios upfront
There are some synchronisation issues that derive from the app thread adding more folios to the rolling buffer whilst the collector thread is looking at them or trying to clear them, such as determining the setting of front_folio_order when the next folio hasn't been added yet,
The reason for the rolling buffer approach is that loading the buffer upfront and then dropping all the refs just acquired is quite a slow operation, and loading progressively allows some of the cost to be deferred until after at least some of the I/O is started.
Instead, a better way is to load all the folios into the rolling buffer upfront - and then drop the refs later, once the I/O is in progress. (Even better would be for the refs not to be there at all.)
Fix this by changing the rolling buffer loader to load all the folios selected by the VM for readahead upfront into the folio queue. The folio queue is allocated a batch worth at a time as we don't know how many folios are involved (the readahead_control struct, alas, has a page count, not a folio count).
The folio refs acquired from readahead are then dropped in bulk once the first subrequest is dispatched as it's quite a slow operation. The collector waits for NETFS_RREQ_NEED_PUT_RA_REFS to be cleared so that it doesn't unlock folios before the xarray has been scanned for them.
This simplifies the buffer handling later and isn't noticeably slower as the xarray doesn't need to be modified and the folios are all already pre-locked.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel's netfs subsystem experienced a critical synchronization vulnerability related to its readahead mechanism, specifically involving the management of memory pages known as folios within a rolling buffer architecture. This issue stemmed from a race condition where an application thread would add new folios to the rolling buffer while a collector thread was simultaneously attempting to inspect or clear those same structures. The core technical flaw lay in the timing of operations; for instance, determining the setting of front_folio_order required knowledge of the next available folio, but if that folio had not yet been added by the application thread due to asynchronous processing, the system would operate on incomplete data. This lack of atomicity in buffer management created a window where concurrent access could lead to undefined behavior or corruption of internal state structures used for managing network filesystem operations.
The underlying design choice that contributed to this vulnerability was an optimization strategy aimed at deferring costs associated with reference counting and memory allocation. The original approach attempted to load the buffer progressively, allowing some overhead to be deferred until after I/O had already begun. However, this progressive loading model introduced complexity in synchronization because it required constant coordination between threads adding data and threads consuming or cleaning up that data. The attempt to optimize performance by spreading out resource acquisition inadvertently created a fragile state where the collector thread could not reliably determine which folios were safe to process without risking access to uninitialized or concurrently modified memory regions. This represents a classic case of concurrency control failure, often categorized under CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization.
The operational impact of this vulnerability includes potential data corruption during readahead operations for network filesystems such as NFS or CIFS. When the collector thread attempts to unlock folios before the xarray has been properly scanned and updated, it can lead to memory leaks where references are not correctly released, or worse, use-after-free scenarios if a folio is accessed after its lifecycle has ended due to improper locking sequences. In high-throughput network environments, these synchronization errors could manifest as intermittent kernel panics, data integrity violations, or significant performance degradation due to retries and error handling overhead. The vulnerability affects the stability of systems relying on efficient asynchronous I/O patterns common in modern Linux kernels.
To resolve this issue, the fix restructures the readahead logic to load all selected folios into the rolling buffer upfront before any processing begins. This change ensures that when the collector thread operates, it has a complete and static view of the data set for the current request batch. The implementation allocates the folio queue in batches based on the page count provided by the readahead control structure, acknowledging that direct folio counts are not always immediately available. Crucially, reference counting is deferred; instead of releasing references incrementally during processing, they are dropped in bulk once the first subrequest is dispatched and I/O is actively progressing. A specific synchronization primitive, NETFS_RREQ_NEED_PUT_RA_REFS, was introduced to ensure the collector waits until this flag is cleared before attempting to unlock folios, thereby guaranteeing that the xarray has been fully scanned and updated.
This architectural shift simplifies buffer handling by removing the need for complex real-time coordination between adding and consuming threads during the critical path of I/O dispatch. By pre-locking all involved folios upfront, the system avoids modifying the xarray during active processing, which reduces contention and potential race conditions. Although loading all references initially might seem counterintuitive to performance optimization, benchmarks indicate that this approach is not noticeably slower because it eliminates the overhead of repeated synchronization checks and allows for more efficient bulk operations later in the pipeline. This fix aligns with best practices for concurrent programming by favoring batch processing over fine-grained incremental updates when atomicity cannot be easily maintained across multiple threads.
From a threat modeling perspective, this vulnerability highlights risks associated with CWE-367: Time-of-check Time-of-use (TOCTOU) race conditions within kernel subsystems. Attackers or malicious workloads could potentially exploit these timing windows to cause denial of service through resource exhaustion or memory corruption if the race condition can be triggered reliably under specific load patterns. The mitigation strategy reflects a move towards more robust synchronization primitives and clearer separation of concerns between data preparation and execution phases in network filesystem drivers. Security practitioners should ensure that kernel updates incorporating this fix are applied promptly, particularly on systems running high-performance network storage configurations where readahead efficiency is critical for both performance and stability.