CVE-2026-80810: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-80810 Overview

CVE-2026-80810 is a Linux kernel vulnerability in the io_uring/rsrc subsystem. The flaw resides in io_vec_fill_bvec(), which computes a folio size using a plain int literal shifted by an unsigned integer taken from imu->folio_shift. On 64-bit kernels, folio_shift can be 32 or greater when the registered buffer is backed by a gigantic hugetlb page. Shifting int 1 by 32 or more triggers undefined behavior, and on x86 and arm64 the shift count is taken modulo 32, producing an incorrect folio size. The result is an out-of-bounds write to the res_bvec array and an out-of-bounds read from imu->bvec.

Critical Impact
A local process with permission to register io_uring buffers backed by 16G hugetlb pages can trigger out-of-bounds memory access in the kernel, leading to memory corruption or denial of service.

Affected Products

Linux kernel versions containing the vulnerable io_vec_fill_bvec() implementation in io_uring/rsrc
64-bit architectures supporting folio shifts of 32 or greater, notably arm64 with 64K pages (CONT_PMD_SHIFT = 34)
powerpc systems supporting gigantic hugetlb pages of 16G or larger

Discovery Timeline

2026-09-04 - CVE-2026-80810 published to NVD
2026-09-04 - Last updated in NVD database

Technical Details for CVE-2026-80810

Vulnerability Analysis

The defect is an integer overflow caused by an undersized shift operand in the io_uring resource management code. The offending statement reads:

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

The literal 1 is treated as int. When imu->folio_shift is 32 or greater, the shift is undefined per the C standard. On x86 and arm64 CPUs, the shift amount is masked to 5 bits, so a shift of 34 yields 4 rather than 16 GiB. Every other folio_shift usage in the same file already uses 1UL, making this an isolated typing bug with disproportionate consequences.

Root Cause

The segment estimator io_estimate_bvec_size() correctly sizes the bvec array using the real shift:

max_segs += (iov[i].iov_len >> shift) + 2;

A 1M iovec on a 16G folio therefore reserves only 2 segments. However, io_vec_fill_bvec() walks the same iovec in chunks of the miscomputed folio_size (4 bytes instead of 16 GiB). This causes roughly 250,000 writes into res_bvec[bvec_idx] past the end of the allocated array, and src_bvec is advanced past imu->bvec in lockstep. validate_fixed_range() bounds only the buffer range, not the segment count.

Attack Vector

Exploitation requires a local user with the ability to allocate gigantic hugetlb pages (16G on arm64 with 64K pages, or equivalent on powerpc) and register them as fixed buffers via io_uring. x86_64 caps hugetlb pages at 1G, which corresponds to a shift of 30 and fits safely in int, so x86_64 systems are not affected. Successful exploitation produces kernel heap out-of-bounds writes, typically resulting in kernel memory corruption, panic, or potential privilege escalation depending on adjacent allocations.

See the upstream fix commit for the one-line correction replacing 1 with 1UL.

Detection Methods for CVE-2026-80810

Indicators of Compromise

Unexpected kernel oops or panic messages referencing io_vec_fill_bvec or io_uring/rsrc in dmesg or /var/log/kern.log
KASAN reports flagging out-of-bounds writes to res_bvec or reads past imu->bvec when io_uring workloads run on systems with gigantic hugetlb allocations
Unexplained memory corruption symptoms coincident with processes registering fixed buffers backed by hugetlbfs

Detection Strategies

Enumerate running kernels with uname -r across arm64 and powerpc fleets and compare against the fixed stable kernel commits referenced in the advisory
Audit processes calling io_uring_register with IORING_REGISTER_BUFFERS against hugetlbfs-backed memory using eBPF or auditd
Run KASAN-enabled kernels in test environments to surface the out-of-bounds access when exercising io_uring against 16G hugetlb pages

Monitoring Recommendations

Collect kernel logs centrally and alert on crash signatures involving io_uring resource paths
Track hugetlbfs allocations of gigantic page sizes on arm64 and powerpc production hosts
Monitor io_uring feature usage through Linux audit rules covering the io_uring_setup and io_uring_register syscalls

How to Mitigate CVE-2026-80810

Immediate Actions Required

Apply the stable kernel updates containing the fix on all arm64 and powerpc hosts that support gigantic hugetlb pages
Restrict which users and containers can allocate gigantic hugetlb pages and register io_uring fixed buffers
Disable io_uring for untrusted workloads using sysctl kernel.io_uring_disabled=2 where operationally feasible

Patch Information

The fix replaces the int literal 1 with 1UL in io_vec_fill_bvec(), matching the rest of the file. Patched commits are available in the mainline and stable trees:

Workarounds

Prevent allocation of gigantic hugetlb pages (16G on arm64 with 64K pages, or equivalent on powerpc) by not configuring hugepagesz=16G or CONT_PMD sized pools
Set kernel.io_uring_disabled=1 or 2 via sysctl to restrict io_uring to privileged users or disable it entirely
Deploy seccomp policies that block io_uring_setup and io_uring_register for workloads that do not require them

bash

# Disable io_uring for unprivileged users system-wide
sysctl -w kernel.io_uring_disabled=2
echo 'kernel.io_uring_disabled=2' >> /etc/sysctl.d/99-io-uring.conf

# Verify no gigantic hugetlb pools are configured
cat /proc/meminfo | grep -i huge
ls /sys/kernel/mm/hugepages/