Resource Exhaustion Affecting kernel-livepatch-6.12.113-138.209 package, versions <1:1.0-0.amzn2023
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
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-KERNELLIVEPATCH612113138209-21809108
- published29 Oct 2026
- disclosed18 Oct 2026
Introduced: 18 Oct 2026
NewCVE-2026-98801 (opens in a new tab)How to fix?
Upgrade Amazon-Linux:2023 kernel-livepatch-6.12.113-138.209 to version 1:1.0-0.amzn2023 or higher.
This issue was patched in ALAS2023-2026-3335.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-livepatch-6.12.113-138.209 package and not the kernel-livepatch-6.12.113-138.209 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:
net: restrict SO_RESERVE_MEM to TCP sockets and cap max value
Commit 2bb2f5fb21b0 ("net: add new socket option SO_RESERVE_MEM") and commit d00c8ee31729 ("net: fix possible NULL deref in sock_reserve_memory") only checked sk_has_account(sk), which is true for both TCP and UDP sockets.
However, SO_RESERVE_MEM and sk_unused_reserved_mem() are currently only supported by TCP:
- On UDP sockets, sk->sk_forward_alloc is protected by sk->sk_receive_queue.lock, whereas sock_reserve_memory() and sock_release_reserved_memory() only acquire lock_sock(sk). Concurrent UDP packet reception/release and setsockopt(SO_RESERVE_MEM) corrupt sk_forward_alloc and memcg accounting.
- udp_rmem_release() reclaims excess sk_forward_alloc without accounting for sk_unused_reserved_mem(sk).
Restrict sock_reserve_memory() to TCP sockets (sk_is_tcp(sk)) for now. Supporting SO_RESERVE_MEM for UDP (acquiring sk_receive_queue.lock and honoring sk_unused_reserved_mem() in udp_rmem_release()) can be done in a future net-next series if needed.
In addition, reject val > SZ_1G with -EINVAL in sk_setsockopt(SO_RESERVE_MEM). Without an upper bound, values near INT_MAX cause sk_mem_pages(delta) and (pages << PAGE_SHIFT) to overflow 32-bit signed int, corrupting sk->sk_forward_alloc and sk->sk_reserved_mem. Using a page-aligned cap (SZ_1G) ensures that the page-rounded sk->sk_reserved_mem reported by getsockopt(SO_RESERVE_MEM) can always be passed back to setsockopt(SO_RESERVE_MEM).
References
- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-98801
- https://git.kernel.org/stable/c/37e02c42a00be692c06343e11779aadc45f45971
- https://git.kernel.org/stable/c/492e04f9a00f3cc88a1f6899417b10f3019a624e
- https://git.kernel.org/stable/c/5069ce898148bd799395c5a464e006cbb840f188
- https://git.kernel.org/stable/c/a467b05b201b5c26be52ed3081992fa9c0387648