Description
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.
Published: 2026-09-17
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Resource Exhaustion (potential DoS)
Action: Assess Impact
AI Analysis

Impact

The fault occurs in the Linux kernel’s iomap subsystem, where a folio batch is not released when certain iomap callback functions fail. The batch holds references to memory pages; if left unreleased, successive failures can exhaust available memory, leading to system instability or denial of service. The vulnerability is confined to internal kernel operations and does not involve external input or user privileges directly; its primary impact is a resource leak that could degrade kernel performance and availability.

Affected Systems

This weakness affects Linux operating system kernels. No specific vendors or product versions are listed, so all distributions that ship the affected kernel code before the applied patch are potentially impacted.

Risk and Exploitability

The EPSS score is quoted as less than 1%, indicating a very low probability of exploitation, and the vulnerability is not listed in the CISA KEV catalog. The attack vector would require triggering the failing iomap callback path, such as through XFS filesystem error conditions. Because the bug is limited to an internal kernel operation, successful exploitation most likely necessitates local or privileged access and would manifest as memory exhaustion rather than remote code execution. The overall risk, given its low EPSS and lack of active exploits, is considered low but should be mitigated before any remediation plans are finalized.

Generated by OpenCVE AI on September 19, 2026 at 05:15 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update the Linux kernel to a release that incorporates the iomap batch cleanup correction.
  • Reboot into the updated kernel and use memory monitoring tools (e.g., vmstat, top) to verify that folio batches are released after filesystem errors.
  • Establish a routine log review of XFS and kernel error messages to detect abnormal patterns that might indicate a residual batch leak.

Generated by OpenCVE AI on September 19, 2026 at 05:15 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 19 Sep 2026 05:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-772

Thu, 17 Sep 2026 16:30:00 +0000

Type Values Removed Values Added
Description 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.
Title iomap: release the folio batch on iomap callback failures
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-17T16:09:20.536Z

Reserved: 2026-09-11T19:38:34.809Z

Link: CVE-2026-90384

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-17T17:17:37.777

Modified: 2026-09-17T17:17:37.777

Link: CVE-2026-90384

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-19T07:15:13Z

Weaknesses
  • CWE-772

    Missing Release of Resource after Effective Lifetime