Independent & educational platform Not a government body. No link or affiliation with any government organisation. Made for learning only. Test only systems you own or are authorised to test. Become a Partner or Sponsor → Full disclaimer

CVE-2026-98801

Severity not reported
Data quality: partial. Some fields were not provided by the source.

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:…

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
—
Awaiting analysis by NVD
Timeline (UTC)
Published: 2026-10-18 16:17
Modified: 2026-10-19 10:19
NVD status: Received
Last synced 1 day ago
Verified against the source API 2026-10-27 07:03 UTC
Exploitation
Not listed in CISA KEV (as of last catalog sync)
Absence from KEV does not mean a CVE is not exploited. Exploitation status: unknown (no authoritative evidence in our sources).

Affected products

Not reported by the source (unknown — not "none").

Mitigation & advisories

No vendor advisory or patch reference tagged by NVD. Check the references below.

References

Data sources

NVD CVE API 2.0 — fetched 2026-10-27 07:03 UTC · record ↗

Learn the basics

Understanding CVEs and CVSS Scores