CVE-2026-80810

In the Linux kernel, the following vulnerability has been resolved:

io uring/rsrc: fix folio size overflow in io vec fill bvec()

io vec fill bvec() computes the folio size with a plain int 1:

unsigned long folio size = 1 << imu->folio shift;

imu->folio shift is unsigned int and comes from folio shift() of the folio backing the registered buffer, so it can be 32 or more on a 64 bit kernel. Shifting int 1 that far is undefined, and on x86 and arm64 the count is taken modulo 32, so a shift of 34 yields 4 rather than 16G. Every other folio shift shift in this file already uses 1UL.

The result is that the segment estimate and the fill loop disagree. io estimate bvec size() sizes the bvec array with the real shift:

max segs += (iov[i].iov len >> shift) + 2;

so a 1M iovec on a 16G folio is charged 2 segments, while io vec fill bvec() then walks the same iovec in folio size chunks of 4 bytes and writes res bvec[bvec idx] a quarter of a million times, past the end of the array it was given. src bvec is advanced once per iteration as well, so imu->bvec is read past its end at the same time. validate fixed range() only checks that the range is inside the registered buffer and does not bound the segment count.

Reaching it needs a folio with a shift of at least 32, which means a gigantic hugetlb page: 16G on arm64 with 64K pages, where CONT PMD SHIFT is 34 and hugetlb add hstate(CONT PMD SHIFT - PAGE SHIFT) registers that size, and likewise on powerpc. x86 64 tops out at 1G, so a shift of 30, which still fits in int and is unaffected.

Use 1UL, as the rest of the file does.