CVE-2026-80810

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

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

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

unsigned long folio_size = 1 << imu->folio_shift;

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 folio_shift shift in this file already uses 1UL.

The result is that the segment estimate and the fill loop disagree. ioestimatebvec_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 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. validatefixed_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 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.