CVE-2026-31463

What it actually does

This is a Linux kernel memory-safety flaw in the iomap read path. Under specific filesystem I/O conditions where the inode block size matches the folio size but differs from the actual I/O granularity, the kernel can retain a stale current-folio pointer after submitting a partial read. The I/O completion helper may then finish or release ownership of the folio while the higher-level iomap read-end path still tries to operate on it, creating invalid folio access. Depending on kernel configuration, allocator state, filesystem, and reachable I/O path, this can result in kernel memory corruption, kernel crash, data corruption, or potentially privilege-impacting behavior. The CVSS vector rates this as network-reachable, unauthenticated, low-complexity, and high impact to confidentiality, integrity, and availability, but no public exploit maturity or CISA KEV listing is currently indicated, and EPSS remains low and flat at approximately 0.0038 over 30 days.

Why it matters to the business

Successful exploitation could destabilize Linux systems, cause kernel panics, interrupt hosted applications, corrupt data being read from affected filesystems, or potentially enable deeper compromise if memory corruption can be controlled. Organizations with Linux servers providing file, storage, container, virtualization, or network-facing file services should treat this as important because a kernel-level defect can affect the whole host and all workloads on it. Current external exploitation signals are low: it is not listed in CISA KEV, is not associated with ransomware use, has no reported exploit maturity, and EPSS has remained low; however, the high CVSS score means remediation should still be prioritized for exposed or high-value Linux systems.

How an attack unfolds

An attacker first needs a way to trigger reads through an affected Linux kernel filesystem path that uses iomap under the vulnerable conditions. This could be direct local access to files, access through a service that causes the kernel to read attacker-influenced file content or layout, or a network-facing storage/file service if it exposes the vulnerable I/O behavior. The attacker then causes reads where the folio size, inode block size, and I/O granularity interact in the vulnerable pattern, leading the kernel to submit less than a full folio while failing to clear the current folio reference. When I/O completion occurs, the helper may complete or release the folio, while the iomap read-end logic later accesses it again. The immediate visible result may be a kernel oops, panic, filesystem error, or availability loss. In a more advanced scenario, an attacker would attempt to shape timing, memory reuse, and page-cache state to turn the invalid folio access into controlled kernel memory corruption, potentially affecting confidentiality or integrity. No named threat actors or public exploit maturity were provided for this vulnerability.

How to fix it

Upgrade affected Linux kernels to a vendor-provided release that includes the iomap fix which unconditionally invalidates the current folio for the no-ifs case. Because no exact fixed package versions were provided, use the relevant distribution or appliance vendor advisory for precise package names and minimum fixed kernel builds. Prioritize internet-facing systems, storage nodes, container hosts, virtualization hosts, file servers, and systems that process untrusted file content. If immediate patching is not possible, reduce exposure by limiting untrusted access to file services, disabling or restricting affected network file-sharing paths where feasible, isolating high-risk workloads, and applying compensating controls such as host reboot scheduling, monitoring for kernel faults, and rapid failover readiness. Runtime mitigations are not a substitute for the kernel fix because the vulnerable behavior is in core kernel filesystem I/O handling.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package is at or above the vendor-fixed version, not merely installed on disk. On Linux systems, compare `uname -r` with the distribution vendor advisory and confirm package manager output such as `rpm -q kernel`, `dpkg -l 'linux-image*'`, or the equivalent appliance/kernel inventory source. Validate that systems were rebooted into the fixed kernel after update. Where source or changelog validation is used, confirm inclusion of the iomap change that clears or invalidates `ctx->cur_folio` unconditionally for the `!ifs` case. To detect remaining exposure, inventory Linux kernel versions across servers and appliances, map them to vendor advisories for CVE-2026-31463, and prioritize any system still running an affected kernel build. Functional validation should focus on absence of recurring kernel oops, panic, KASAN, or filesystem read-path errors during representative storage and file-service workloads after patching.

Typical attack path

1. Identify a reachable Linux system running an affected kernel and a filesystem or service path that exercises iomap reads.
2. Gain the ability to cause file reads through that path, either locally or through an exposed service that reads attacker-controlled or attacker-influenced data.
3. Craft I/O patterns that create the vulnerable mismatch between folio size, inode block size, and I/O granularity.
4. Trigger partial folio reads so the kernel submits I/O without invalidating the current folio reference in the no-ifs case.
5. Cause the I/O completion path and iomap read-end path to act on the same folio incorrectly, producing invalid folio access.
6. Observe or leverage the result, ranging from kernel crash and service outage to possible kernel memory corruption if exploitation can be made reliable.

How to detect it

There are no unique network indicators or attacker-specific artifacts provided for this vulnerability. Detection should focus on evidence of attempted triggering or successful faulting in kernel and system logs, especially around filesystem read activity. Review `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, crash dump infrastructure, kernel panic records, hypervisor console logs, and EDR telemetry for kernel oops, KASAN reports, general protection faults, page or folio reference errors, and stack traces involving iomap read functions. Correlate kernel faults with file-service access logs such as NFS, SMB/Samba, web upload/download services, object gateways, backup systems, or content-processing applications that could cause reads of attacker-influenced files. For forensic review, preserve vmcore/kdump artifacts and examine stack traces for `iomap_read_folio_iter`, `iomap_read_end`, `folio_end_read`, or related filesystem read completion functions. Repeated crashes during similar file-read operations, especially from the same remote client or workload, should be treated as suspicious even if exploitation cannot be proven.

• iomap_read_folio_iter
• iomap_read_end
• folio_end_read
• invalid folio
• BUG: KASAN
• KASAN: use-after-free
• KASAN: slab-use-after-free
• general protection fault
• kernel BUG at
• Oops:
• Kernel panic - not syncing
• unable to handle kernel paging request
• page dumped because: VM_BUG_ON_FOLIO
• VM_BUG_ON_FOLIO
• refcount_t: underflow
• BUG: Bad page state
• BUG: Bad page map
• /var/log/kern.log
• /var/log/messages
• journalctl -k
• dmesg

What your security team should do

• Patch or upgrade affected Linux kernels using vendor-fixed releases, with highest priority for exposed file services, storage infrastructure, virtualization hosts, Kubernetes/container nodes, and critical production servers.
• Verify that updated systems have rebooted into the fixed kernel; do not rely only on package installation status.
• Create an asset query for Linux kernel versions and track remediation against the relevant vendor advisories, since exact fixed versions vary by distribution.
• Increase monitoring for kernel oops, panic, KASAN, iomap, folio, and filesystem read-path errors until patching is complete.
• Restrict untrusted access to services that can cause server-side file reads, especially network file-sharing, storage gateway, backup, content-processing, and multi-tenant workload paths.
• Because the vulnerability is not in CISA KEV, has no known ransomware association, and has low stable EPSS, balance emergency response with exposure: prioritize externally reachable and high-impact systems first, then complete fleet-wide kernel maintenance.