CVE-2025-21710

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