CVE-2026-98801: net: restrict SO_RESERVE_MEM to TCP sockets and cap max value
In the Linux kernel, the following vulnerability has been resolved:
net: restrict SORESERVEMEM to TCP sockets and cap max value
Commit 2bb2f5fb21b0 ("net: add new socket option SORESERVEMEM") and commit d00c8ee31729 ("net: fix possible NULL deref in sockreservememory") only checked skhasaccount(sk), which is true for both TCP and UDP sockets.
However, SORESERVEMEM and skunusedreservedmem() are currently only supported by TCP: - On UDP sockets, sk->skforwardalloc is protected by sk->skreceivequeue.lock, whereas sockreservememory() and sockreleasereservedmemory() only acquire locksock(sk). Concurrent UDP packet reception/release and setsockopt(SORESERVEMEM) corrupt skforwardalloc and memcg accounting. - udprmemrelease() reclaims excess skforwardalloc without accounting for skunusedreservedmem(sk).
Restrict sockreservememory() to TCP sockets (skistcp(sk)) for now. Supporting SORESERVEMEM for UDP (acquiring skreceivequeue.lock and honoring skunusedreservedmem() in udprmemrelease()) can be done in a future net-next series if needed.
In addition, reject val > SZ1G with -EINVAL in sksetsockopt(SORESERVEMEM). Without an upper bound, values near INTMAX cause skmempages(delta) and (pages << PAGESHIFT) to overflow 32-bit signed int, corrupting sk->skforwardalloc and sk->skreservedmem. Using a page-aligned cap (SZ1G) ensures that the page-rounded sk->skreservedmem reported by getsockopt(SORESERVEMEM) can always be passed back to setsockopt(SORESERVEMEM).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Restrict sock_reserve_memory() and SO_RESERVE_MEM to TCP sockets (sk_is_tcp(sk)), and reject SO_RESERVE_MEM values above SZ_1G with -EINVAL.
Linux kernel SO_RESERVE_MEM sock_reserve_memory() socket restriction and maximum value = TCP sockets only; reject values greater than SZ_1G with -EINVAL
Event History
Frequently Asked Questions
Which socket types are exposed to the accounting corruption?
UDP sockets are exposed when SO_RESERVE_MEM is used. The option and its reserved-memory handling are currently supported only for TCP, but the prior checks allowed UDP sockets to use it.
What is required to trigger the issue?
An attacker or local process needs to set SO_RESERVE_MEM on a UDP socket while UDP packet reception or release occurs concurrently. This can corrupt sk_forward_alloc and memory-cgroup accounting.
Are oversized SO_RESERVE_MEM values also addressed?
Yes. The fix rejects SO_RESERVE_MEM values greater than SZ_1G with -EINVAL; the provided information does not specify the impact of unbounded values beyond stating that an upper bound was missing.