Cloudanix VulnDB

CVE-2026-98801

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's network memory handling could let attackers corrupt internal memory tracking when certain network options are used on non-TCP connections, risking crashes on affected systems.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Data Tampering
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The flaw permits setsockopt(SO_RESERVE_MEM) on UDP sockets (via insufficient sk_has_account check instead of sk_is_tcp) and lacks an upper bound on the value, enabling concurrent sk_forward_alloc corruption under sk_receive_queue.lock, incorrect memcg accounting, and integer overflow in sk_mem_pages when values approach INT_MAX.

Why it matters to the business

Systems relying on UDP networking may experience crashes, memory accounting errors, or denial of service; recent kernel exposure increases urgency for environments with high UDP traffic or custom socket tuning.

How an attack unfolds

An attacker creates a UDP socket, calls setsockopt(SO_RESERVE_MEM) with a large or crafted value, then triggers concurrent packet reception or release paths that race on sk_forward_alloc and bypass reserved memory accounting in udp_rmem_release, leading to corrupted kernel memory structures.

How to fix it

Upgrade to a Linux kernel containing commit 2bb2f5fb21b0 and d00c8ee31729 plus the restricting change that enforces sk_is_tcp(sk) and rejects values > SZ_1G; rebuild and reboot affected systems; avoid custom SO_RESERVE_MEM usage on UDP until full UDP support lands.

How to confirm the fix worked

Verify kernel source contains the sk_is_tcp restriction and SZ_1G cap in sock_setsockopt; confirm getsockopt(SO_RESERVE_MEM) returns page-aligned values only on TCP sockets and fails with EINVAL on UDP or oversized requests.

Typical attack path

  1. Create UDP socket via socket(AF_INET, SOCK_DGRAM)
  2. Invoke setsockopt with SO_RESERVE_MEM and large/invalid value
  3. Induce concurrent UDP receive or send traffic to trigger race
  4. Observe corruption in sk_forward_alloc or memcg counters

How to detect it

Search kernel logs and audit trails for setsockopt failures or warnings around SO_RESERVE_MEM on non-TCP sockets; inspect for unexpected sk_forward_alloc or memcg accounting discrepancies during UDP traffic; review strace or eBPF traces of socket option calls.

  • setsockopt.*SO_RESERVE_MEM
  • sk_is_tcp
  • sock_reserve_memory
  • sk_unused_reserved_mem

What your security team should do

  • Patch all Linux kernels within 30 days given recent publication
  • Audit user-space code for SO_RESERVE_MEM usage and restrict to TCP
  • Monitor UDP-heavy workloads for unexplained crashes or OOM anomalies
  • Add kernel build-time checks or runtime tests for the new socket option restrictions

The record

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).

Affected packages

Ecosystem Package Introduced Fixed