Linux kernel iomap: invalid folio access when block size differs from read I/O granularity

CVSS 9.8CVE-2026-31463Kernel, userspace & hypervisorcurated

Impact

The iomap buffered-read path can call iomap_read_end() on a folio after the I/O helper has already taken ownership of it and will finish the read itself. This happens when the inode block size matches the folio size but the I/O is submitted in smaller pieces, for folios with no iomap_folio_state attached. The result is an invalid access to page-cache memory, which can corrupt memory or crash the kernel on hosts whose filesystems use iomap for buffered reads (XFS, for example). The record does not show a privilege-escalation path. The NVD score of 9.8 with a network vector is not supported by the description, which reads as a local filesystem I/O condition.

Who can reach it

Local. Needs a process that can do buffered reads on an iomap-backed filesystem in the affected block-size and I/O-granularity configuration. The record does not say that any privilege is needed beyond file read access.

What to do

Install a kernel that contains the referenced stable commits (the record lists the 7.0 series as affected), then drain and reboot each node. The record names no mitigation that avoids a reboot.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-31463 https://git.kernel.org/stable/c/4a927f670cdb0def226f9f85f42a9f19d9e09c88 https://git.kernel.org/stable/c/bd71fb3fea9945987053968f028a948997cba8cc

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.