Homepage

CVE-2026-80811 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-20249522
  • published29 Sept 2026
  • disclosed4 Sept 2026
Report a new vulnerability Found a mistake?

Introduced: 4 Sep 2026

NewCVE-2026-80811  (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/cmd: fix iovec leak when the async cmd is not recycled

An io_async_cmd carries an iovec array in ->vec.iovec, allocated when the vec has to grow and kept across recycling through ctx->cmd_cache. On two paths nothing frees it and io_clean_op()'s kfree(req->async_data) drops the io_async_cmd without it.

io_req_uring_cleanup() clears the async data flags only when io_alloc_cache_put() succeeds, and the cache holds IO_ALLOC_CACHE_MAX == 128 entries, so once it is full the put fails and the vec is left behind. An NVMe passthrough workload gets there without doing anything unusual: nvme_uring_cmd_io() returns -EIOCBQUEUED, so the io_async_cmd stays attached for the lifetime of the command and the live object count tracks the queue depth. Above 128 the puts start failing.

->cleanup is the last chance to free an inherited vec, since io_req_uring_cleanup() returns early for an io-wq issued command and is not called at all for one completed without ever being issued. But io_clean_op() calls ->cleanup only if REQ_F_NEED_CLEANUP is set, and for uring_cmd that happens only where the vec has to grow, so a command reusing a large enough cached vec never sets it. io_rw_alloc_async() and io_msg_alloc_async() flag an inherited vec for exactly this reason; io_uring_cmd_prep() does not.

Flag an inherited vec in io_uring_cmd_prep(), and free the vec when the cache put fails, as io_req_rw_cleanup() does.

The leak is invisible under KASAN, where io_alloc_cache_vec_kasan() frees the vec unconditionally.