{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-31463", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2026-03-09T15:48:24.092Z", "datePublished": "2026-04-22T13:53:54.224Z", "dateUpdated": "2026-04-22T13:53:54.224Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2026-04-22T13:53:54.224Z"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\niomap: fix invalid folio access when i_blkbits differs from I/O granularity\n\nCommit aa35dd5cbc06 (\"iomap: fix invalid folio access after\nfolio_end_read()\") partially addressed invalid folio access for folios\nwithout an ifs attached, but it did not handle the case where\n1 << inode->i_blkbits matches the folio size but is different from the\ngranularity used for the IO, which means IO can be submitted for less\nthan the full folio for the !ifs case.\n\nIn this case, the condition:\n\n if (*bytes_submitted == folio_len)\n ctx->cur_folio = NULL;\n\nin iomap_read_folio_iter() will not invalidate ctx->cur_folio, and\niomap_read_end() will still be called on the folio even though the IO\nhelper owns it and will finish the read on it.\n\nFix this by unconditionally invalidating ctx->cur_folio for the !ifs\ncase."}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["fs/iomap/buffered-io.c"], "versions": [{"version": "b2f35ac4146d32d4424aaa941bbc681f12c1b9e6", "lessThan": "4a927f670cdb0def226f9f85f42a9f19d9e09c88", "status": "affected", "versionType": "git"}, {"version": "b2f35ac4146d32d4424aaa941bbc681f12c1b9e6", "lessThan": "bd71fb3fea9945987053968f028a948997cba8cc", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["fs/iomap/buffered-io.c"], "versions": [{"version": "6.19", "status": "affected"}, {"version": "0", "lessThan": "6.19", "status": "unaffected", "versionType": "semver"}, {"version": "6.19.11", "lessThanOrEqual": "6.19.*", "status": "unaffected", "versionType": "semver"}, {"version": "7.0", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "cpeApplicability": [{"nodes": [{"operator": "OR", "negate": false, "cpeMatch": [{"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.19", "versionEndExcluding": "6.19.11"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.19", "versionEndExcluding": "7.0"}]}]}], "references": [{"url": "https://git.kernel.org/stable/c/4a927f670cdb0def226f9f85f42a9f19d9e09c88"}, {"url": "https://git.kernel.org/stable/c/bd71fb3fea9945987053968f028a948997cba8cc"}], "title": "iomap: fix invalid folio access when i_blkbits differs from I/O granularity", "x_generator": {"engine": "bippy-1.2.0"}}}}

{}

{"cveTags": [], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\niomap: fix invalid folio access when i_blkbits differs from I/O granularity\n\nCommit aa35dd5cbc06 (\"iomap: fix invalid folio access after\nfolio_end_read()\") partially addressed invalid folio access for folios\nwithout an ifs attached, but it did not handle the case where\n1 << inode->i_blkbits matches the folio size but is different from the\ngranularity used for the IO, which means IO can be submitted for less\nthan the full folio for the !ifs case.\n\nIn this case, the condition:\n\n if (*bytes_submitted == folio_len)\n ctx->cur_folio = NULL;\n\nin iomap_read_folio_iter() will not invalidate ctx->cur_folio, and\niomap_read_end() will still be called on the folio even though the IO\nhelper owns it and will finish the read on it.\n\nFix this by unconditionally invalidating ctx->cur_folio for the !ifs\ncase."}], "id": "CVE-2026-31463", "lastModified": "2026-04-22T14:16:42.323", "metrics": {}, "published": "2026-04-22T14:16:42.323", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/4a927f670cdb0def226f9f85f42a9f19d9e09c88"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/bd71fb3fea9945987053968f028a948997cba8cc"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Received"}

{}

{"affected": [{"configurations": [{"platform": null, "status": "affected", "versions": {"scheme": "code_commit", "value": "[b2f35ac4146d32d4424aaa941bbc681f12c1b9e6,4a927f670cdb0def226f9f85f42a9f19d9e09c88)"}}, {"platform": null, "status": "affected", "versions": {"scheme": "code_commit", "value": "[b2f35ac4146d32d4424aaa941bbc681f12c1b9e6,bd71fb3fea9945987053968f028a948997cba8cc)"}}], "enrichment": {"confidence": 99.0, "confidence_source": "inferred", "scores": [{"score": 99.0, "source": "inferred"}, {"score": 100.0, "source": "matching"}]}, "original": {"product": "Linux", "source": "cna", "vendor": "Linux"}, "product": "linux_kernel", "vendor": "linux"}, {"configurations": [{"platform": null, "status": "affected", "versions": {"scheme": "generic", "value": "6.19"}}, {"platform": null, "status": "unaffected", "versions": {"scheme": "generic", "value": "[0,6.19)"}}, {"platform": null, "status": "unaffected", "versions": {"scheme": "generic", "value": "[6.19.11,6.19.*]"}}, {"platform": null, "status": "unaffected", "versions": {"scheme": "generic", "value": "[7.0,*]"}}], "enrichment": {"confidence": 99.0, "confidence_source": "inferred", "scores": [{"score": 99.0, "source": "inferred"}, {"score": 100.0, "source": "matching"}]}, "original": {"product": "Linux", "source": "cna", "vendor": "Linux"}, "product": "linux_kernel", "vendor": "linux"}], "analysis": {"en": {"generated_at": "2026-04-22T19:04:02.048817+00:00", "value": {"mitigation_remediation": ["Upgrade the Linux kernel to a version that includes commit aa35dd5cbc06, which unconditionally invalidates ctx->cur_folio for the non\u2011IFS case.", "If using a custom kernel, recompile the kernel with the patch commit applied.", "As a short\u2011term measure, avoid performing I/O operations on files whose block sizes do not match the system's I/O granularity until the kernel is updated."], "summary": {"action": "Immediate Patch", "impact": "Kernel memory corruption could lead to arbitrary code execution or denial of service."}, "threat_synthesis": {"affected_systems": "This vulnerability affects all releases of the Linux kernel in which the faulty code path exists, until the patch identified by commit aa35dd5cbc06 is applied. The affected systems are any Linux installations running a kernel prior to this commit, regardless of distribution or architecture, because the flaw resides in core kernel files. The exact version range cannot be listed because the data does not provide a version list.", "description_and_impact": "The Linux kernel contains an issue in the iomap subsystem that allows an invalid folio to be accessed when the inode block size differs from the I/O granularity. In this scenario the read iterator fails to clear the current folio, causing the end helper to operate on a folio that is still owned by the I/O helper. This mismanaging of kernel memory can result in corruption of kernel data structures, potentially giving an attacker the ability to execute arbitrary code or crash the system. The weakness stems from improper resource handling and read iterator logic.", "risk_and_exploitability": "No CVSS or EPSS scores are available, and the issue is not listed in CISA KEV. The lack of publicly documented exploitation reduces immediate risk, but kernel memory corruption remains a high\u2011consequence issue. The likely attack vector requires the attacker to cause the kernel to read from a file whose block size configuration triggers the mis\u2011aligned i_blkbits pattern, which implies local or privileged access. Consequently, the vulnerability should be treated as a high\u2011risk kernel issue until the relevant patch is deployed."}}}}, "created": "2026-04-22T19:15:24.477051+00:00", "updated": "2026-04-22T20:30:26.554165+00:00", "vendors": ["linux", "linux$PRODUCT$linux_kernel"], "weaknesses": ["CWE-682", "CWE-665"]}