<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 29 Sep 2026 17:18:58 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-21710 — tcp: correct handling of extreme memory squeeze</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-21710</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;tcp: correct handling of extreme memory squeeze&lt;/p&gt;
&lt;p&gt;Testing with iperf3 using the &amp;#34;pasta&amp;#34; protocol splicer has revealed
a problem in the way tcp handles window advertising in extreme memory
squeeze situations.&lt;/p&gt;
&lt;p&gt;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&amp;#39;t influence any further calculations.&lt;/p&gt;
&lt;p&gt;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&amp;#39;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;The following excerpt of a logging session, with own comments added,
shows more in detail what is happening:&lt;/p&gt;
&lt;p&gt;//              tcp_v4_rcv(-&amp;gt;)
//                tcp_rcv_established(-&amp;gt;)
[5201&amp;lt;-&amp;gt;39222]:     ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====
[5201&amp;lt;-&amp;gt;39222]:     tcp_data_queue(-&amp;gt;)
[5201&amp;lt;-&amp;gt;39222]:        DROPPING skb [265600160..…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;tcp: correct handling of extreme memory squeeze&lt;/p&gt;
&lt;p&gt;Testing with iperf3 using the &amp;#34;pasta&amp;#34; protocol splicer has revealed
a problem in the way tcp handles window advertising in extreme memory
squeeze situations.&lt;/p&gt;
&lt;p&gt;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&amp;#39;t influence any further calculations.&lt;/p&gt;
&lt;p&gt;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&amp;#39;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;The following excerpt of a logging session, with own comments added,
shows more in detail what is happening:&lt;/p&gt;
&lt;p&gt;//              tcp_v4_rcv(-&amp;gt;)
//                tcp_rcv_established(-&amp;gt;)
[5201&amp;lt;-&amp;gt;39222]:     ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====
[5201&amp;lt;-&amp;gt;39222]:     tcp_data_queue(-&amp;gt;)
[5201&amp;lt;-&amp;gt;39222]:        DROPPING skb [265600160..…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2025-21710</guid>
    </item>
  </channel>
</rss>
