CVE-2026-80810: io_uring/rsrc: fix folio size overflow in io_vec_fill_bvec()

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

iouring/rsrc: fix folio size overflow in iovecfillbvec()

iovecfillbvec() computes the folio size with a plain int 1:

unsigned long foliosize = 1 << imu->folioshift;

imu->folioshift is unsigned int and comes from folioshift() 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 folioshift shift in this file already uses 1UL.

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

maxsegs += (iov[i].iovlen >> shift) + 2;

so a 1M iovec on a 16G folio is charged 2 segments, while iovecfillbvec() then walks the same iovec in foliosize chunks of 4 bytes and writes resbvec[bvecidx] a quarter of a million times, past the end of the array it was given. srcbvec is advanced once per iteration as well, so imu->bvec is read past its end at the same time. validatefixedrange() 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 CONTPMDSHIFT is 34 and hugetlbaddhstate(CONTPMDSHIFT - PAGESHIFT) registers that size, and likewise on powerpc. x8664 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.