{"api_version":"1","generated_at":"2026-04-23T06:54:46+00:00","cve":"CVE-2026-31463","urls":{"html":"https://cve.report/CVE-2026-31463","api":"https://cve.report/api/cve/CVE-2026-31463.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-31463","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-31463"},"summary":{"title":"iomap: fix invalid folio access when i_blkbits differs from I/O granularity","description":"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.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-04-22 14:16:42","updated_at":"2026-04-22 14:16:42"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/4a927f670cdb0def226f9f85f42a9f19d9e09c88","name":"https://git.kernel.org/stable/c/4a927f670cdb0def226f9f85f42a9f19d9e09c88","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/bd71fb3fea9945987053968f028a948997cba8cc","name":"https://git.kernel.org/stable/c/bd71fb3fea9945987053968f028a948997cba8cc","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-31463","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31463","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected b2f35ac4146d32d4424aaa941bbc681f12c1b9e6 4a927f670cdb0def226f9f85f42a9f19d9e09c88 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected b2f35ac4146d32d4424aaa941bbc681f12c1b9e6 bd71fb3fea9945987053968f028a948997cba8cc git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.19","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.19 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.19.11 6.19.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.0 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["fs/iomap/buffered-io.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"4a927f670cdb0def226f9f85f42a9f19d9e09c88","status":"affected","version":"b2f35ac4146d32d4424aaa941bbc681f12c1b9e6","versionType":"git"},{"lessThan":"bd71fb3fea9945987053968f028a948997cba8cc","status":"affected","version":"b2f35ac4146d32d4424aaa941bbc681f12c1b9e6","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["fs/iomap/buffered-io.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"6.19"},{"lessThan":"6.19","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.19.*","status":"unaffected","version":"6.19.11","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.0","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.19.11","versionStartIncluding":"6.19","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.0","versionStartIncluding":"6.19","vulnerable":true}],"negate":false,"operator":"OR"}]}],"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."}],"providerMetadata":{"dateUpdated":"2026-04-22T13:53:54.224Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"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"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-31463","datePublished":"2026-04-22T13:53:54.224Z","dateReserved":"2026-03-09T15:48:24.092Z","dateUpdated":"2026-04-22T13:53:54.224Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-04-22 14:16:42","lastModifiedDate":"2026-04-22 14:16:42","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"31463","Ordinal":"1","Title":"iomap: fix invalid folio access when i_blkbits differs from I/O ","CVE":"CVE-2026-31463","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"31463","Ordinal":"1","NoteData":"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.","Type":"Description","Title":"iomap: fix invalid folio access when i_blkbits differs from I/O "}]}}}