CVE-2026-90384 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
iomap: release the folio batch on iomap callback failures
A sashiko review of an unrelated patch points out that the folio batch mechanism used for iomap zero range fails to release the batch in a couple error scenarios. If either calls to ->iomap_end() or ->iomap_begin() fail, the direct return paths bypass the batch cleanup.
The ->iomap_end() case is not a practical issue at the moment because there is no user of the mechanism that returns an error from this path. The ->iomap_begin() case is theoretically possible because XFS can invoke the fill helper and error out at various points thereafter. This subtly complicates things because XFS does not transfer iomap_flags to the iomap data structure in the error path.
To deal with both of these issues, first make sure to invoke the cleanup helper in the error path for either fs callback. Second, update the helper to clear the flag unconditionally and release the batch so long as it is populated. This more clearly delineates the purpose of the flag to control the I/O path and not necessarily the status of the fbatch, so add a comment around this as well.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's iomap subsystem manages block mapping for file operations, utilizing a folio batch mechanism to optimize zero-range writes by batching memory allocations and releases. A recent code review identified a critical resource management flaw where the folio batch is not properly released during specific error conditions within the iomap callback lifecycle. Specifically, when either the ->iomap_begin() or ->iomap_end() callbacks fail, the direct return paths in the kernel source bypass the necessary cleanup routines responsible for releasing the allocated folios. This oversight results in a memory leak where allocated page structures remain pinned and unreleased even though the operation has failed, leading to potential resource exhaustion over time if such errors occur frequently enough within a running system.
The severity of this vulnerability varies depending on which callback fails. The failure path associated with ->iomap_end() is currently considered low risk because no existing filesystem implementations return an error from this specific point in the execution flow. However, the scenario involving ->iomap_begin() presents a more tangible threat vector. Filesystems such as XFS invoke fill helpers that can encounter errors at various stages after initialization but before completion. In these cases, the kernel fails to transfer iomap_flags correctly during the error path, further complicating state management and ensuring that the batch cleanup logic is not triggered. This creates a situation where memory resources are consumed without corresponding release, potentially degrading system performance or stability under heavy I/O load with frequent failures.
From a technical classification perspective, this vulnerability aligns with CWE-401, which describes missing release of memory after successful allocation, and CWE-755, relating to improper handling of unusual input conditions that lead to resource leaks. In the context of the MITRE ATT&CK framework, while not directly exploitable for privilege escalation or data exfiltration in its current state due to the limited practical impact on ->iomap_end(), it represents a weakness in robustness and error handling that could be leveraged in denial-of-service scenarios if an attacker can induce repeated iomap failures. The lack of proper cleanup violates fundamental principles of secure coding by failing to maintain invariant states during exception paths, thereby reducing the overall resilience of the kernel's file system layer against resource exhaustion attacks.
To mitigate this vulnerability, developers have implemented a fix that ensures the cleanup helper is invoked unconditionally in the error paths for both filesystem callbacks. The updated logic clears relevant flags and releases the folio batch provided it contains populated entries, effectively decoupling the I/O path control from the status of the folio batch itself. This change includes added comments to clarify the purpose of specific flags, ensuring that future maintainers understand the distinction between controlling I/O behavior and managing resource lifecycle. System administrators should apply kernel updates containing this patch to prevent potential memory leaks in environments where filesystem operations may frequently encounter errors, particularly those involving XFS or other complex storage stacks that rely heavily on iomap zero-range optimizations.