CVE-2026-98801net: restrict SO_RESERVE_MEM to TCP sockets and cap max value
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
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).
- CVSS
- Not yet scored
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Oct 18, 2026
- First seen by InfoSec Signals
- Oct 18, 2026
Affected products
Linux Linux linux:linux (from the name) | from 2bb2f5fb21b0486ff69b7b4a1fe03a760527d133 before 492e04f9a00f3cc88a1f6899417b10f3019a624e; from 2bb2f5fb21b0486ff69b7b4a1fe03a760527d133 before 5069ce898148bd799395c5a464e006cbb840f188; from 2bb2f5fb21b0486ff69b7b4a1fe03a760527d133 before a467b05b201b5c26be52ed3081992fa9c0387648; from 2bb2f5fb21b0486ff69b7b4a1fe03a760527d133 before 37e02c42a00be692c06343e11779aadc45f45971 | CNA record |
References
- https://git.kernel.org/stable/c/492e04f9a00f3cc88a1f6899417b10f3019a624e
- https://git.kernel.org/stable/c/5069ce898148bd799395c5a464e006cbb840f188
- https://git.kernel.org/stable/c/a467b05b201b5c26be52ed3081992fa9c0387648
- https://git.kernel.org/stable/c/37e02c42a00be692c06343e11779aadc45f45971
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.