CVE Tools

CVE-2026-98299

tcp: do not let tcp_rmem be set below 4096

No known exploitation. EPSS puts it in the 7th percentile. Fixed versions are out.

Published Updated Sources: CVE.org, NVD

What to do

Find your product and version, then upgrade to the build on the right.

  • LinuxAffected: ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < 879907631b9e70eedb62d76461b29afa106ebe7aUpgrade to: 879907631b9e70eedb62d76461b29afa106ebe7aAffected: ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < 8e32532d0fa3191ecf9524b0e6bafa0832e712baUpgrade to: 8e32532d0fa3191ecf9524b0e6bafa0832e712baAffected: ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < 67b83c15bed9eeeb8d1a6dbf88a5f79525970173Upgrade to: 67b83c15bed9eeeb8d1a6dbf88a5f79525970173Affected: ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < 9a4f49bf8d2da4e52e904f60c29cca317bab9b3aUpgrade to: 9a4f49bf8d2da4e52e904f60c29cca317bab9b3a + 4 more branchesStated by: CVE record

Versions as the sources state them. Full version matrix after sign-in

What it is

From the CVE record

In the Linux kernel, the following vulnerability has been resolved: tcp: do not let tcp_rmem be set below 4096 We can hit a division by zero crash in tcp_rcvbuf_grow() and tcp_rcv_space_adjust(): divide error: 0000 [#1] PREEMPT SMP RIP: 0010:tcp_rcvbuf_grow+0x187/0x450 net/ipv4/tcp_input.c:939 ... grow = div_u64(((u64)rcvwin << 1) * (newval - oldval), oldval); The division uses oldval = tp->rcvq_space.space as divisor. When tp->rcvq_space.space is zero, this leads to a divide-by-zero exception. tp->rcvq_space.space is initialized in tcp_init_buffer_space(): tp->rcvq_space.space = min3(tp->rcv_ssthresh, tp->rcv_wnd, (u32)TCP_INIT_CWND * tp->advmss); If tcp_rmem[1] is configured to very small values (such as 1), sk->sk_rcvbuf is initialized to 1. Then tcp_full_space(sk), which computes (sk->sk_rcvbuf * scaling_ratio) >> 8, truncates to 0. This sets tp->window_clamp = 0, tp->rcv_ssthresh = 0, and tp->rcvq_space.space = 0. Later, when data arrives and DRS is invoked, tcp_rcvbuf_grow() divides by oldval == 0. Back in 2015, commit b1cb59cf2efe ("net: sysctl_net_core: check SNDBUF and RCVBUF for min length") ensured that net.core.rmem_default and net.core.rmem_max cannot be set below SOCK_MIN_RCVBUF. Similarly, SO_RCVBUF setsockopt enforces max_t(int, val * 2, SOCK_MIN_RCVBUF). However, net.ipv4.tcp_rmem still had .extra1 = SYSCTL_ONE, allowing arbitrarily small values. Because SOCK_MIN_RCVBUF depends on sizeof(struct sk_buff) and cacheline alignment, its value varies across architectures and configuration options. Using a fixed constant of 4096 ensures a predictable, architecture- independent lower bound that is safely above SOCK_MIN_RCVBUF everywhere and matches the documented 4K default. Fix this by setting tcp_rmem.extra1 to 4096 and updating the documentation.

In plain language

No plain-language summary for this CVE yet.

Exploitation

Where each signal puts this CVE on the scale from published to confirmed exploited.

EPSS7th
CISA KEV

Not in the catalog. CISA has not confirmed exploitation.

Public exploits

No public exploit or proof of concept found in the sources we track.

EPSS

0.2% chance of exploitation activity in the next 30 days, which ranks it in the 7th percentile of scored CVEs.

Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.

Lifecycle

2 events over 0 days, from the signal feeds we watch.

  1. Publishedrecord updated

Affected products

Sources

Watch the software you run.

My Stack ranks new CVEs for your products by real-world exploitation, so the next serious one reaches you without reading every advisory.

We'll flag the next CVE, public exploit or patch for Linux, not every advisory.