<?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://cve.radiocsirt.org</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>Mon, 05 Oct 2026 20:10:52 +0000</lastBuildDate>
    <item>
      <title>CVE-2021-47304 — tcp: fix tcp_init_transfer() to not reset icsk_ca_initialized</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2021-47304</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: fix tcp_init_transfer() to not reset icsk_ca_initialized&lt;/p&gt;
&lt;p&gt;This commit fixes a bug (found by syzkaller) that could cause spurious
double-initializations for congestion control modules, which could cause
memory leaks or other problems for congestion control modules (like CDG)
that allocate memory in their init functions.&lt;/p&gt;
&lt;p&gt;The buggy scenario constructed by syzkaller was something like:&lt;/p&gt;
&lt;p&gt;(1) create a TCP socket
(2) initiate a TFO connect via sendto()
(3) while socket is in TCP_SYN_SENT, call setsockopt(TCP_CONGESTION),
    which calls:
       tcp_set_congestion_control() -&amp;gt;
         tcp_reinit_congestion_control() -&amp;gt;
           tcp_init_congestion_control()
(4) receive ACK, connection is established, call tcp_init_transfer(),
    set icsk_ca_initialized=0 (without first calling cc-&amp;gt;release()),
    call tcp_init_congestion_control() again.&lt;/p&gt;
&lt;p&gt;Note that in this sequence tcp_init_congestion_control() is called
twice without a cc-&amp;gt;release() call in between. Thus, for CC modules
that allocate memory in their init() function, e.g, CDG, a memory leak
may occur. The syzkaller tool managed to find a reproducer that
triggered such a leak in CDG.&lt;/p&gt;
&lt;p&gt;The bug was introduced when that commit 8919a9b31eb4 (&amp;#34;tcp: Only init
congestion control if not initialized already&amp;#34;)
introduced icsk_ca_initialized and set icsk_ca_initialized to 0 in
tcp_init_transfer(), missing the possibility for a sequence like the
one above, where a pro…&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: fix tcp_init_transfer() to not reset icsk_ca_initialized&lt;/p&gt;
&lt;p&gt;This commit fixes a bug (found by syzkaller) that could cause spurious
double-initializations for congestion control modules, which could cause
memory leaks or other problems for congestion control modules (like CDG)
that allocate memory in their init functions.&lt;/p&gt;
&lt;p&gt;The buggy scenario constructed by syzkaller was something like:&lt;/p&gt;
&lt;p&gt;(1) create a TCP socket
(2) initiate a TFO connect via sendto()
(3) while socket is in TCP_SYN_SENT, call setsockopt(TCP_CONGESTION),
    which calls:
       tcp_set_congestion_control() -&amp;gt;
         tcp_reinit_congestion_control() -&amp;gt;
           tcp_init_congestion_control()
(4) receive ACK, connection is established, call tcp_init_transfer(),
    set icsk_ca_initialized=0 (without first calling cc-&amp;gt;release()),
    call tcp_init_congestion_control() again.&lt;/p&gt;
&lt;p&gt;Note that in this sequence tcp_init_congestion_control() is called
twice without a cc-&amp;gt;release() call in between. Thus, for CC modules
that allocate memory in their init() function, e.g, CDG, a memory leak
may occur. The syzkaller tool managed to find a reproducer that
triggered such a leak in CDG.&lt;/p&gt;
&lt;p&gt;The bug was introduced when that commit 8919a9b31eb4 (&amp;#34;tcp: Only init
congestion control if not initialized already&amp;#34;)
introduced icsk_ca_initialized and set icsk_ca_initialized to 0 in
tcp_init_transfer(), missing the possibility for a sequence like the
one above, where a pro…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2021-47304</guid>
    </item>
  </channel>
</rss>
