HIGH Introduced in 5.16
net SO_RESERVE_MEM Race
CVE-2026-98801
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
01Description
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).
02KernelScan AI Analysis
Risk summary
A local user can trigger a race condition or integer overflow in the SO_RESERVE_MEM socket option on UDP sockets, corrupting kernel memory accounting. This allows privilege escalation from an unprivileged local account to full kernel compromise. Any system with memory cgroups enabled and local user access is at risk.
Vulnerability analysis
The SO_RESERVE_MEM socket option was originally implemented with a check that allowed both TCP and UDP sockets to use it, but the underlying memory reservation logic only works correctly for TCP. On UDP sockets, the socket's forward memory allocation is protected by a different lock than the one used by the reservation code, so concurrent packet reception and a setsockopt call can corrupt the memory accounting fields. Additionally, the option accepted arbitrarily large values, causing an integer overflow when converting the value to pages, which also corrupts kernel memory state. The fix restricts the option to TCP sockets only and caps the maximum value at 1 GB. Any local user who can create a UDP socket and call setsockopt can trigger this vulnerability, provided memory cgroups are enabled on the system.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 6.12 | 5.16 | 6.12.113 | 492e04f9a00f |
| 6.18 | 5.16 | 6.18.56 | 5069ce898148 |
| 7.2 | 5.16 | 7.2.10 | a467b05b201b |
| mainline | 5.16 | 7.3 | 37e02c42a00b |
04CIP Kernels
State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.
| CIP tree | State |
|---|---|
| cip/6.12 | Affected — no CIP fix yet (latest 6.12.112-cip33) |
| cip/6.1 | Affected — no CIP fix yet (latest 6.1.189-cip61) |
| cip/6.1-rt | Affected — no CIP fix yet (latest 6.1.189-cip61-rt32) |