{"id":"CVE-2026-80810","title":"io_uring/rsrc: fix folio size overflow in io_vec_fill_bvec()","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/rsrc: fix folio size overflow in io_vec_fill_bvec()\n\nio_vec_fill_bvec() computes the folio size with a plain int 1:\n\n\tunsigned long folio_size = 1 << imu->foli…","severity":"none","vendor":"Linux","product":"Linux","affected":["Linux >= 9ef4cbbcb4ac3786a1a4164507511b76b2a572c5 < 45c945107e007b1fb73e21cd220277652a45521a","Linux >= 9ef4cbbcb4ac3786a1a4164507511b76b2a572c5 < 6b308c37fbeba3aa8c634fb1ed53e2f63a5d5a5c","Linux >= 9ef4cbbcb4ac3786a1a4164507511b76b2a572c5 < 3267d7c8ba51642117f7bdd1ece02b2540668476","Linux >= 9ef4cbbcb4ac3786a1a4164507511b76b2a572c5 < 3f3a6a16bbe8bde76532d9415438f8cdef439e5d","Linux 6.15"],"published":"2026-09-04","updated":"2026-10-19","sourceUpdated":"2026-10-19T08:44:03.724Z","source":"CVEORG","sourceUrl":"https://www.cve.org/CVERecord?id=CVE-2026-80810","references":[{"url":"https://git.kernel.org/stable/c/45c945107e007b1fb73e21cd220277652a45521a"},{"url":"https://git.kernel.org/stable/c/6b308c37fbeba3aa8c634fb1ed53e2f63a5d5a5c"},{"url":"https://git.kernel.org/stable/c/3267d7c8ba51642117f7bdd1ece02b2540668476"},{"url":"https://git.kernel.org/stable/c/3f3a6a16bbe8bde76532d9415438f8cdef439e5d"}],"tags":["cve.org"],"epss":0.00209,"epssPercentile":0.10306,"ingestedAt":"2026-10-19T09:16:01.509Z","slug":"CVE-2026-80810","body":"## Overview\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/rsrc: fix folio size overflow in io_vec_fill_bvec()\n\nio_vec_fill_bvec() computes the folio size with a plain int 1:\n\n\tunsigned long folio_size = 1 << imu->folio_shift;\n\nimu->folio_shift is unsigned int and comes from folio_shift() of the\nfolio backing the registered buffer, so it can be 32 or more on a 64 bit\nkernel. Shifting int 1 that far is undefined, and on x86 and arm64 the\ncount is taken modulo 32, so a shift of 34 yields 4 rather than 16G.\nEvery other folio_shift shift in this file already uses 1UL.\n\nThe result is that the segment estimate and the fill loop disagree.\nio_estimate_bvec_size() sizes the bvec array with the real shift:\n\n\tmax_segs += (iov[i].iov_len >> shift) + 2;\n\nso a 1M iovec on a 16G folio is charged 2 segments, while\nio_vec_fill_bvec() then walks the same iovec in folio_size chunks of 4\nbytes and writes res_bvec[bvec_idx] a quarter of a million times, past\nthe end of the array it was given. src_bvec is advanced once per\niteration as well, so imu->bvec is read past its end at the same time.\nvalidate_fixed_range() only checks that the range is inside the\nregistered buffer and does not bound the segment count.\n\nReaching it needs a folio with a shift of at least 32, which means a\ngigantic hugetlb page: 16G on arm64 with 64K pages, where\nCONT_PMD_SHIFT is 34 and hugetlb_add_hstate(CONT_PMD_SHIFT - PAGE_SHIFT)\nregisters that size, and likewise on powerpc. x86_64 tops out at 1G, so\na shift of 30, which still fits in int and is unaffected.\n\nUse 1UL, as the rest of the file does.\n\n## Affected\n\n- `Linux >= 9ef4cbbcb4ac3786a1a4164507511b76b2a572c5 < 45c945107e007b1fb73e21cd220277652a45521a`\n- `Linux >= 9ef4cbbcb4ac3786a1a4164507511b76b2a572c5 < 6b308c37fbeba3aa8c634fb1ed53e2f63a5d5a5c`\n- `Linux >= 9ef4cbbcb4ac3786a1a4164507511b76b2a572c5 < 3267d7c8ba51642117f7bdd1ece02b2540668476`\n- `Linux >= 9ef4cbbcb4ac3786a1a4164507511b76b2a572c5 < 3f3a6a16bbe8bde76532d9415438f8cdef439e5d`\n- `Linux 6.15`\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.","depth":"sunlit","depthScore":3,"depthScoreParts":{"impact":2.8,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}