CVE-2026-90384
NoneCVSS
—
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A memory-handling mistake in the Linux kernel can cause crashes or let attackers gain extra access on affected computers.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Theoretical
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Patch
- Effort
- Low
- Patch risk
- Low
What it actually does
Failure to release the folio batch in iomap zero-range error paths (iomap_begin or iomap_end callbacks) leaves a populated batch referenced after the controlling flag is cleared, enabling a use-after-free in the Linux kernel iomap subsystem.
Why it matters to the business
Linux systems using XFS or other iomap-based filesystems may experience kernel crashes, memory corruption, or potential local privilege escalation, affecting server availability and data integrity.
How an attack unfolds
An attacker crafts filesystem operations that invoke iomap zero-range while forcing an error return from iomap_begin (possible via XFS fill-helper paths) or iomap_end; the missed batch release allows subsequent use of the now-freed folio structures.
How to fix it
Apply the upstream iomap fix that ensures the cleanup helper is called on both callback error paths and that the helper unconditionally clears the flag and releases any populated batch.
How to confirm the fix worked
Confirm the running kernel contains the corrected iomap.c logic; exercise zero-range operations under error injection for both callbacks and verify no batch leaks occur.
Typical attack path
- Mount or access an XFS filesystem that exercises iomap zero-range
- Trigger conditions that cause iomap_begin to return an error after partial batch population
- Reuse the dangling folio batch reference from userspace or kernel context
- Achieve memory corruption or crash
How to detect it
Review kernel logs for iomap-related warnings or oopses around folio batch handling; inspect XFS error paths and any custom iomap users for unexpected early returns.
What your security team should do
- Prioritize kernel updates containing the iomap batch-release fix on all XFS/iomap-using systems
- Monitor for new stable kernel releases and schedule staged rollouts
- Harden XFS filesystems with strict error-handling testing in staging environments
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|