Homepage

CVE-2026-80810 Affecting kernel6.18-modules-extra-common package, versions <1:6.18.48-107.148.amzn2023

Severity

 Recommended
high

Based on Amazon Linux security rating.

Threat Intelligence

EPSS
0.21% (10th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-AMZN2023-KERNEL618MODULESEXTRACOMMON-20249760
  • published29 Sept 2026
  • disclosed4 Sept 2026
Report a new vulnerability Found a mistake?

Introduced: 4 Sep 2026

NewCVE-2026-80810  (opens in a new tab)

How to fix?

Upgrade Amazon-Linux:2023 kernel6.18-modules-extra-common to version 1:6.18.48-107.148.amzn2023 or higher.
This issue was patched in ALAS2023-2026-3139.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel6.18-modules-extra-common package and not the kernel6.18-modules-extra-common package as distributed by Amazon-Linux. See How to fix? for Amazon-Linux:2023 relevant fixed versions and status.

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 &lt;&lt; imu-&gt;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 &gt;&gt; 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.