CVE-2026-80810 in Linux
Summary
by MITRE • 09/04/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The Linux kernel vulnerability identified involves an integer overflow within the io_uring subsystem, specifically in the io_vec_fill_bvec function responsible for handling buffer vector operations. The core technical flaw stems from the use of a signed int type with a value of one when computing folio sizes via bit shifting. Specifically, the code executes unsigned long folio_size = 1 << imu->folio_shift where imu->folio_shift is an unsigned integer derived from the backing folio's shift amount. On 64-bit architectures such as x86 and arm64, this shift value can reach thirty-two or higher for large memory pages. Shifting a signed int by more than its bit width constitutes undefined behavior according to C standards. In practice on these platforms, the operation wraps modulo thirty-two, meaning a requested shift of thirty-four results in a size of four bytes rather than the intended sixteen gigabytes. This discrepancy creates a critical mismatch between segment estimation and actual buffer filling logic.
The operational impact of this flaw is severe memory corruption due to out-of-bounds writes and reads. The io_estimate_bvec_size function correctly calculates the required array size using the accurate shift value, charging only two segments for large input vectors on huge pages. However, io_vec_fill_bvec proceeds with the erroneously small four-byte chunk size derived from the overflowed calculation. Consequently, when processing a one-megabyte iovec against a sixteen-gigabyte folio, the loop iterates approximately a quarter of a million times instead of twice. This causes res_bvec to be written far beyond its allocated bounds and src_bvec to be read past its end simultaneously. The validation function validate_fixed_range only verifies that the memory range falls within registered buffers but fails to constrain the segment count or verify array boundaries, allowing this buffer overflow to execute unchecked during normal io_uring operations involving large pages.
Exploitation of this vulnerability requires specific hardware and kernel configuration conditions. It necessitates a folio with a shift value of at least thirty-two, which corresponds to gigantic hugetlb pages such as sixteen-gigabyte pages on arm64 systems utilizing sixty-four-kilobyte base pages where CONT_PMD_SHIFT is set to thirty-four. Similarly, powerpc architectures support comparable large page sizes that trigger this condition. On x86_64 platforms, the maximum supported huge page size corresponds to a shift of thirty, which remains within the safe range for signed int shifting and thus does not exhibit this vulnerability. This limitation restricts the attack surface primarily to systems configured with extremely large memory pages on architectures supporting CONT_PMD_SHIFT or equivalent mechanisms.
The resolution involves correcting the data type used in the bit shift operation by changing the literal one from a signed int to an unsigned long, denoted as 1UL. This aligns the implementation with existing practices throughout the rest of the source file and ensures that shifts up to sixty-three are handled correctly without overflow or undefined behavior. From a security classification perspective, this issue maps to CWE-190 Integer Overflow or Wraparound in terms of root cause and CWE-787 Out-of-bounds Write regarding its impact. In the context of attack techniques, it relates to ATT&CK Tactic TA0004 Privilege Escalation as successful exploitation could potentially lead to kernel memory corruption and arbitrary code execution with elevated privileges. Mitigation strategies include applying the provided kernel patch immediately for affected systems utilizing large hugetlb pages on vulnerable architectures. Administrators should also monitor io_uring usage patterns involving massive buffers and consider restricting huge page allocations if immediate patching is not feasible, although updating the kernel remains the definitive remediation step to eliminate this memory safety violation.