CVE-2026-31463
published 2026-04-22CVE-2026-31463: In the Linux kernel, the following vulnerability has been resolved: iomap: fix invalid folio access when i_blkbits differs from I/O granularity Commit…
PriorityP348critical9.8CVSS 3.1
AVNACLPRNUINSUCHIHAH
EPSS
0.38%
30.2th percentile
In the Linux kernel, the following vulnerability has been resolved:
iomap: fix invalid folio access when i_blkbits differs from I/O granularity
Commit aa35dd5cbc06 ("iomap: fix invalid folio access after
folio_end_read()") partially addressed invalid folio access for folios
without an ifs attached, but it did not handle the case where
1 i_blkbits matches the folio size but is different from the
granularity used for the IO, which means IO can be submitted for less
than the full folio for the !ifs case.
In this case, the condition:
if (*bytes_submitted == folio_len)
ctx->cur_folio = NULL;
in iomap_read_folio_iter() will not invalidate ctx->cur_folio, and
iomap_read_end() will still be called on the folio even though the IO
helper owns it and will finish the read on it.
Fix this by unconditionally invalidating ctx->cur_folio for the !ifs
case.
Affected
5 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| linux | linux | — | — |
| linux | linux | >= b2f35ac4146d32d4424aaa941bbc681f12c1b9e6 < 4a927f670cdb0def226f9f85f42a9f19d9e09c88 | 4a927f670cdb0def226f9f85f42a9f19d9e09c88 |
| linux | linux | >= b2f35ac4146d32d4424aaa941bbc681f12c1b9e6 < bd71fb3fea9945987053968f028a948997cba8cc | bd71fb3fea9945987053968f028a948997cba8cc |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 6.19 < 6.19.11 | 6.19.11 |
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: iomap: fix invalid folio access when i_blkbits differs from I/O granularity
vendor_redhat·2026-04-22
CVE-2026-31463 CWE-821 kernel: iomap: fix invalid folio access when i_blkbits differs from I/O granularity
kernel: iomap: fix invalid folio access when i_blkbits differs from I/O granularity
A flaw was found in the Linux kernel's iomap subsystem. This vulnerability occurs when the block size of an inode (`i_blkbits`) differs from the granularity used for input/output (I/O) operations. This mismatch can lead to invalid access of data pages (folios) during read operations, potentially causing data corruption or system instability. The issue arises because the system may attempt to finalize a read operation on a folio that is still actively being processed by the I/O helper.
Package: kernel (Red Hat Enterprise Linux 10) - Not affected
Package: kernel (Red Hat Enterprise Linux 6) - Not affected
Package: kernel (Red Hat Enterprise Linux 7) - Not affected
Package: kernel-rt (Red Hat Enterprise L
GHSA
GHSA-rprr-w46r-7762: In the Linux kernel, the following vulnerability has been resolved:
iomap: fix invalid folio access when i_blkbits differs from I/O granularity
Comm
ghsa_unreviewed·2026-04-22
CVE-2026-31463 GHSA-rprr-w46r-7762: In the Linux kernel, the following vulnerability has been resolved:
iomap: fix invalid folio access when i_blkbits differs from I/O granularity
Comm
In the Linux kernel, the following vulnerability has been resolved:
iomap: fix invalid folio access when i_blkbits differs from I/O granularity
Commit aa35dd5cbc06 ("iomap: fix invalid folio access after
folio_end_read()") partially addressed invalid folio access for folios
without an ifs attached, but it did not handle the case where
1 i_blkbits matches the folio size but is different from the
granularity used for the IO, which means IO can be submitted for less
than the full folio for the !ifs case.
In this case, the condition:
if (*bytes_submitted == folio_len)
ctx->cur_folio = NULL;
in iomap_read_folio_iter() will not invalidate ctx->cur_folio, and
iomap_read_end() will still be called on the folio even though the IO
helper owns it and will finish the read on it.
Fix this by unco
No detection rules found.
No public exploits indexed.
2026-04-22
Published