CVE-2026-80897 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
netfs: release readahead folios on iterator preparation failure
netfs_prepare_read_iterator() batches readahead folios in put_batch so that the folio references can be dropped after the I/O iterator has been prepared.
If rolling_buffer_load_from_ra() fails after earlier folios have been batched, the function returns immediately and leaves those references held. Release the batch before returning the error.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/04/2026
The Linux kernel's network filesystem (netfs) subsystem manages data transfer between remote storage servers and local memory through a complex iterator mechanism that handles read-ahead operations to optimize performance. A critical flaw was identified in the netfs_prepare_read_iterator function, which is responsible for preparing the I/O iterator used during file reads. This function employs an optimization strategy where it batches references to readahead folios into a put_batch structure. The intent of this batching is to defer the release of these memory references until after the I/O iterator has been successfully prepared and validated, thereby reducing overhead associated with immediate reference counting operations for each individual folio.
The vulnerability arises from an error handling path within the netfs_prepare_read_iterator function when it invokes rolling_buffer_load_from_ra. This internal helper is tasked with loading data into a rolling buffer to facilitate efficient sequential reading. If this operation fails after some folios have already been added to the put_batch, the function executes an early return to signal the failure condition. However, in its original implementation, this early exit bypassed the necessary cleanup logic required to release the references held within the batch. Consequently, the kernel retains active references to these memory pages even though the read operation is aborted or fails, leading to a resource leak scenario where folio references are never decremented or freed.
This oversight results in a progressive accumulation of unreleased memory resources over time, particularly under conditions that trigger frequent failures during rolling buffer loading. Such behavior constitutes an information exposure and potential denial of service vector due to the gradual depletion of available kernel memory. As system uptime increases or if specific network conditions cause repeated read-ahead preparation failures, the leaked folio references can contribute to increased memory pressure on the host system. In severe cases, this may lead to out-of-memory conditions affecting not only the netfs subsystem but potentially impacting other critical services running on the same node due to overall resource exhaustion.
From a classification perspective, this issue aligns with CWE-401, which describes missing release of memory after successful allocation or operation failure. The flaw represents an improper cleanup mechanism within kernel space that fails to revert state changes upon error conditions. In terms of tactical mapping, while not directly exploitable for remote code execution in the traditional sense, it falls under resource exhaustion techniques often associated with denial-of-service attacks as defined by MITRE ATT&CK tactics related to impact and availability disruption through resource consumption.
The resolution involves modifying netfs_prepare_read_iterator to ensure that any folios added to the put_batch prior to a failure are properly released before the function returns an error code. This correction ensures that reference counting remains balanced regardless of whether the read preparation succeeds or fails, thereby maintaining system stability and preventing memory leaks. Administrators should apply kernel updates containing this fix to mitigate the risk of gradual resource depletion in environments relying heavily on network filesystems with aggressive read-ahead configurations.