Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1020 CNY

100%

CVE-2025-21710— tcp: correct handling of extreme memory squeeze

EPSS 0.01% · P3

Affected Version Matrix 10

VendorProductVersion RangeStatus
LinuxLinuxe2142825c120d4317abf7160a0fc34b3de532586< b01e7ceb35dcb7ffad413da657b78c3340a09039affected
e2142825c120d4317abf7160a0fc34b3de532586< 1dd823a46e25ffde1492c391934f69a9e5eb574faffected
e2142825c120d4317abf7160a0fc34b3de532586< b4055e2fe96f4ef101d8af0feb056d78d77514ffaffected
e2142825c120d4317abf7160a0fc34b3de532586< 8c670bdfa58e48abad1d5b6ca1ee843ca91f7303affected
6.6affected
< 6.6unaffected
6.6.76≤ 6.6.*unaffected
6.12.13≤ 6.12.*unaffected
… +2 more rows
Get alerts for future matching vulnerabilitiesLog in to subscribe

I. Basic Information for CVE-2025-21710

Vulnerability Information

Have questions about the vulnerability? See if Shenlong's analysis helps!
View Shenlong Deep Dive ↗

Although we use advanced large model technology, its output may still contain inaccurate or outdated information.Shenlong tries to ensure data accuracy, but please verify and judge based on the actual situation.

Vulnerability Title
tcp: correct handling of extreme memory squeeze
Source: NVD (National Vulnerability Database)
Vulnerability Description
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---
Source: NVD (National Vulnerability Database)
CVSS Information
N/A
Source: NVD (National Vulnerability Database)
Vulnerability Type
N/A
Source: NVD (National Vulnerability Database)
Vulnerability Title
Linux kernel 安全漏洞
Source: CNNVD (China National Vulnerability Database)
Vulnerability Description
Linux kernel是美国Linux基金会的开源操作系统Linux所使用的内核。 Linux kernel存在安全漏洞,该漏洞源于tcp在极端内存压力下窗口广告处理不正确。
Source: CNNVD (China National Vulnerability Database)
CVSS Information
N/A
Source: CNNVD (China National Vulnerability Database)
Vulnerability Type
N/A
Source: CNNVD (China National Vulnerability Database)

Affected Products

VendorProductAffected VersionsCPESubscribe
LinuxLinux e2142825c120d4317abf7160a0fc34b3de532586 ~ b01e7ceb35dcb7ffad413da657b78c3340a09039 -
LinuxLinux 6.6 -

II. Public POCs for CVE-2025-21710

#POC DescriptionSource LinkShenlong Link
AI-Generated POCPremium

No public POC found.

Login to generate AI POC

III. Intelligence Information for CVE-2025-21710

登录查看更多情报信息。
Patch · 4

Same Patch Batch · Linux · 2025-02-27 · 177 CVEs total

CVE-2025-217567.8 HIGHvsock: Keep the binding until socket destruction
CVE-2025-21773can: etas_es58x: fix potential NULL pointer dereference on udev->serial
CVE-2025-21763neighbour: use RCU protection in __neigh_notify()
CVE-2025-21762arp: use RCU protection in arp_xmit()
CVE-2025-21764ndisc: use RCU protection in ndisc_alloc_skb()
CVE-2025-21765ipv6: use RCU protection in ip6_default_advmss()
CVE-2025-21766ipv4: use RCU protection in __ip_rt_update_pmtu()
CVE-2025-21767clocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic context
CVE-2025-21769ptp: vmclock: Add .owner to vmclock_miscdev_fops
CVE-2025-21768net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnels
CVE-2025-21771sched_ext: Fix incorrect autogroup migration detection
CVE-2025-21770iommu: Fix potential memory leak in iopf_queue_remove_device()
CVE-2025-21777ring-buffer: Validate the persistent meta data subbuf array
CVE-2025-21783gpiolib: Fix crash on error in gpiochip_get_ngpios()
CVE-2025-21781batman-adv: fix panic during interface removal
CVE-2025-21780drm/amdgpu: avoid buffer overflow attach in smu_sys_set_pp_table()
CVE-2025-21779KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel
CVE-2025-21778tracing: Do not allow mmap() of persistent ring buffer
CVE-2025-21774can: rockchip: rkcanfd_handle_rx_fifo_overflow_int(): bail out if skb cannot be allocated
CVE-2025-21772partitions: mac: fix handling of bogus partition table

Showing top 20 of 177 CVEs. View all on vendor page &rarr; →

IV. Related Vulnerabilities

V. Comments for CVE-2025-21710

No comments yet


Leave a comment