PT-2026-117020 · Linux · Linux
CVE-2026-98801
·
Published
2026-10-18
·
Updated
2026-10-18
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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).
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux