Cloudanix VulnDB

CVE-2025-21710

None

CVSS

—

EPSS

0.3%

Published

Feb 27, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux network stack can freeze data transfers when the system runs low on memory, requiring a connection reset to recover.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Under memory pressure the TCP receive window logic can advertise a zero window without updating internal state, causing the advertised window to remain zero even after memory is freed and preventing the peer from resuming data transmission.

Why it matters to the business

Network connections can stall during periods of high memory usage, leading to degraded performance or outages for services that rely on reliable TCP data transfer.

How an attack unfolds

An attacker or workload drives the target into memory pressure while a TCP connection is active; the kernel then advertises a zero window that is never corrected, leaving the remote peer unable to send further data and the connection effectively hung.

How to fix it

Upgrade the Linux kernel to a version containing the fix for this TCP window advertisement logic; apply the corrected tcp_select_window and __tcp_cleanup_rbuf handling.

How to confirm the fix worked

After patching, reproduce memory-pressure conditions with tools such as iperf3 under the pasta splicer and confirm that non-zero windows are advertised once memory is available.

Typical attack path

  1. Trigger sustained memory pressure on the target system
  2. Establish or use an existing TCP connection carrying data
  3. Force the kernel to drop in-window segments and advertise a zero window
  4. Observe that subsequent window updates remain zero after memory is reclaimed
  5. Connection remains stalled until reset or application-level recovery

How to detect it

Review kernel logs and TCP stack traces for repeated zero-window advertisements under memory-pressure conditions; correlate with SKB_DROP_REASON_PROTO_MEM drops and stalled receive queues.

What your security team should do

  • Prioritize kernel updates on systems exposed to untrusted network traffic or running memory-constrained workloads
  • Monitor for TCP connections that remain idle after memory pressure events
  • Consider enabling TCP keep-alives or application-level timeouts as a temporary mitigation

The record

In the Linux kernel, the following vulnerability has been resolved: tcp: correct handling of extreme memory squeeze Testing with iperf3 using the "pasta" protocol splicer has revealed a problem in the way tcp handles window advertising in extreme memory squeeze situations. Under memory pressure, a socket endpoint may temporarily advertise a zero-sized window, but this is not stored as part of the socket data. The reasoning behind this is that it is considered a temporary setting which shouldn't influence any further calculations. However, if we happen to stall at an unfortunate value of the current window size, the algorithm selecting a new value will consistently fail to advertise a non-zero window once we have freed up enough memory. This means that this side's notion of the current window size is different from the one last advertised to the peer, causing the latter to not send any data to resolve the sitution. The problem occurs on the iperf3 server side, and the socket in question is a completely regular socket with the default settings for the fedora40 kernel. We do not use SO_PEEK or SO_RCVBUF on the socket. The following excerpt of a logging session, with own comments added, shows more in detail what is happening: // tcp_v4_rcv(->) // tcp_rcv_established(->) [5201<->39222]: ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ==== [5201<->39222]: tcp_data_queue(->) [5201<->39222]: DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184] [copied_seq 259909392->260034360 (124968), unread 5565800, qlen 85, ofoq 0] [OFO queue: gap: 65480, len: 0] [5201<->39222]: tcp_data_queue(<-) [5201<->39222]: __tcp_transmit_skb(->) [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160] [5201<->39222]: tcp_select_window(->) [5201<->39222]: (inet_csk(sk)->icsk_ack.pending & ICSK_ACK_NOMEM) ? --> TRUE [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160] returning 0 [5201<->39222]: tcp_select_window(<-) [5201<->39222]: ADVERTISING WIN 0, ACK_SEQ: 265600160 [5201<->39222]: [__tcp_transmit_skb(<-) [5201<->39222]: tcp_rcv_established(<-) [5201<->39222]: tcp_v4_rcv(<-) // Receive queue is at 85 buffers and we are out of memory. // We drop the incoming buffer, although it is in sequence, and decide // to send an advertisement with a window of zero. // We don't update tp->rcv_wnd and tp->rcv_wup accordingly, which means // we unconditionally shrink the window. [5201<->39222]: tcp_recvmsg_locked(->) [5201<->39222]: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160 [5201<->39222]: [new_win = 0, win_now = 131184, 2 * win_now = 262368] [5201<->39222]: [new_win >= (2 * win_now) ? --> time_to_ack = 0] [5201<->39222]: NOT calling tcp_send_ack() [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160] [5201<->39222]: __tcp_cleanup_rbuf(<-) [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184] [copied_seq 260040464->260040464 (0), unread 5559696, qlen 85, ofoq 0] returning 6104 bytes [5201<->39222]: tcp_recvmsg_locked(<-) // After each read, the algorithm for calculating the new receive // window in __tcp_cleanup_rbuf() finds it is too small to advertise // or to update tp->rcv_wnd. // Meanwhile, the peer thinks the window is zero, and will not send // any more data to trigger an update from the interrupt mode side. [5201<->39222]: tcp_recvmsg_locked(->) [5201<->39222]: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160 [5201<->39222]: [new_win = 262144, win_now = 131184, 2 * win_n ---truncated---

Affected packages

Ecosystem Package Introduced Fixed
Debian:13 linux 0 No fix
Debian:13 linux 0 6.12.13-1
Linux Kernel 6.6.0 6.6.76
SUSE:Linux Enterprise High Availability Extension 15 SP6 kernel-default 0 6.4.0-150600.23.81.3
SUSE:Linux Enterprise Live Patching 15 SP6 kernel-default 0 6.4.0-150600.23.81.3
SUSE:Linux Enterprise Live Patching 15 SP6 kernel-livepatch-SLE15-SP6-RT_Update_18 0 1-150600.1.3.1
SUSE:Linux Enterprise Live Patching 15 SP6 kernel-livepatch-SLE15-SP6_Update_18 0 1-150600.13.3.3
SUSE:Linux Enterprise Module for Basesystem 15 SP6 kernel-64kb 0 6.4.0-150600.23.81.3
SUSE:Linux Enterprise Module for Basesystem 15 SP6 kernel-default 0 6.4.0-150600.23.81.3
SUSE:Linux Enterprise Module for Basesystem 15 SP6 kernel-default-base 0 6.4.0-150600.23.81.3.150600.12.36.3
SUSE:Linux Enterprise Module for Basesystem 15 SP6 kernel-source 0 6.4.0-150600.23.81.2
SUSE:Linux Enterprise Module for Basesystem 15 SP6 kernel-zfcpdump 0 6.4.0-150600.23.81.3
SUSE:Linux Enterprise Module for Development Tools 15 SP6 kernel-docs 0 6.4.0-150600.23.81.1
SUSE:Linux Enterprise Module for Development Tools 15 SP6 kernel-obs-build 0 6.4.0-150600.23.81.3
SUSE:Linux Enterprise Module for Development Tools 15 SP6 kernel-source 0 6.4.0-150600.23.81.2
SUSE:Linux Enterprise Module for Development Tools 15 SP6 kernel-syms 0 6.4.0-150600.23.81.1
SUSE:Linux Enterprise Module for Legacy 15 SP6 kernel-default 0 6.4.0-150600.23.81.3
SUSE:Linux Enterprise Module for Public Cloud 15 SP6 kernel-azure 0 6.4.0-150600.8.58.1
SUSE:Linux Enterprise Module for Public Cloud 15 SP6 kernel-source-azure 0 6.4.0-150600.8.58.1
SUSE:Linux Enterprise Module for Public Cloud 15 SP6 kernel-syms-azure 0 6.4.0-150600.8.58.1
SUSE:Linux Enterprise Workstation Extension 15 SP6 kernel-default 0 6.4.0-150600.23.81.3
SUSE:Real Time Module 15 SP6 kernel-rt 0 6.4.0-150600.10.61.1
SUSE:Real Time Module 15 SP6 kernel-rt_debug 0 6.4.0-150600.10.61.1
SUSE:Real Time Module 15 SP6 kernel-source-rt 0 6.4.0-150600.10.61.1
SUSE:Real Time Module 15 SP6 kernel-syms-rt 0 6.4.0-150600.10.61.1
Ubuntu:24.10 linux-aws 0 6.11.0-1014.15
openSUSE:Leap 15.6 dtb-aarch64 0 6.4.0-150600.23.81.1
openSUSE:Leap 15.6 kernel-64kb 0 6.4.0-150600.23.81.3
openSUSE:Leap 15.6 kernel-azure 0 6.4.0-150600.8.58.1
openSUSE:Leap 15.6 kernel-debug 0 6.4.0-150600.23.81.3
openSUSE:Leap 15.6 kernel-default 0 6.4.0-150600.23.81.3
openSUSE:Leap 15.6 kernel-default-base 0 6.4.0-150600.23.81.3.150600.12.36.3
openSUSE:Leap 15.6 kernel-docs 0 6.4.0-150600.23.81.1
openSUSE:Leap 15.6 kernel-kvmsmall 0 6.4.0-150600.23.81.3
openSUSE:Leap 15.6 kernel-obs-build 0 6.4.0-150600.23.81.3
openSUSE:Leap 15.6 kernel-obs-qa 0 6.4.0-150600.23.81.1
openSUSE:Leap 15.6 kernel-rt 0 6.4.0-150600.10.61.1
openSUSE:Leap 15.6 kernel-rt_debug 0 6.4.0-150600.10.61.1
openSUSE:Leap 15.6 kernel-source 0 6.4.0-150600.23.81.2
openSUSE:Leap 15.6 kernel-source-azure 0 6.4.0-150600.8.58.1
openSUSE:Leap 15.6 kernel-source-rt 0 6.4.0-150600.10.61.1
openSUSE:Leap 15.6 kernel-syms 0 6.4.0-150600.23.81.1
openSUSE:Leap 15.6 kernel-syms-azure 0 6.4.0-150600.8.58.1
openSUSE:Leap 15.6 kernel-syms-rt 0 6.4.0-150600.10.61.1
openSUSE:Leap 15.6 kernel-zfcpdump 0 6.4.0-150600.23.81.3

Related vulnerabilities