<?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>Tue, 06 Oct 2026 07:09:04 +0000</lastBuildDate>
    <item>
      <title>CVE-2021-47544 — tcp: fix page frag corruption on page fault</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2021-47544</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 page frag corruption on page fault&lt;/p&gt;
&lt;p&gt;Steffen reported a TCP stream corruption for HTTP requests
served by the apache web-server using a cifs mount-point
and memory mapping the relevant file.&lt;/p&gt;
&lt;p&gt;The root cause is quite similar to the one addressed by
commit 20eb4f29b602 (&amp;#34;net: fix sk_page_frag() recursion from
memory reclaim&amp;#34;). Here the nested access to the task page frag
is caused by a page fault on the (mmapped) user-space memory
buffer coming from the cifs file.&lt;/p&gt;
&lt;p&gt;The page fault handler performs an smb transaction on a different
socket, inside the same process context. Since sk-&amp;gt;sk_allaction
for such socket does not prevent the usage for the task_frag,
the nested allocation modify &amp;#34;under the hood&amp;#34; the page frag
in use by the outer sendmsg call, corrupting the stream.&lt;/p&gt;
&lt;p&gt;The overall relevant stack trace looks like the following:&lt;/p&gt;
&lt;p&gt;httpd 78268 [001] 3461630.850950:      probe:tcp_sendmsg_locked:
        ffffffff91461d91 tcp_sendmsg_locked+0x1
        ffffffff91462b57 tcp_sendmsg+0x27
        ffffffff9139814e sock_sendmsg+0x3e
        ffffffffc06dfe1d smb_send_kvec+0x28
        [...]
        ffffffffc06cfaf8 cifs_readpages+0x213
        ffffffff90e83c4b read_pages+0x6b
        ffffffff90e83f31 __do_page_cache_readahead+0x1c1
        ffffffff90e79e98 filemap_fault+0x788
        ffffffff90eb0458 __do_fault+0x38
        ffffffff90eb5280 do_fault+0x1a0
        ffffffff90eb7c84 __handle_mm_fault+0x4d4
        f…&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 page frag corruption on page fault&lt;/p&gt;
&lt;p&gt;Steffen reported a TCP stream corruption for HTTP requests
served by the apache web-server using a cifs mount-point
and memory mapping the relevant file.&lt;/p&gt;
&lt;p&gt;The root cause is quite similar to the one addressed by
commit 20eb4f29b602 (&amp;#34;net: fix sk_page_frag() recursion from
memory reclaim&amp;#34;). Here the nested access to the task page frag
is caused by a page fault on the (mmapped) user-space memory
buffer coming from the cifs file.&lt;/p&gt;
&lt;p&gt;The page fault handler performs an smb transaction on a different
socket, inside the same process context. Since sk-&amp;gt;sk_allaction
for such socket does not prevent the usage for the task_frag,
the nested allocation modify &amp;#34;under the hood&amp;#34; the page frag
in use by the outer sendmsg call, corrupting the stream.&lt;/p&gt;
&lt;p&gt;The overall relevant stack trace looks like the following:&lt;/p&gt;
&lt;p&gt;httpd 78268 [001] 3461630.850950:      probe:tcp_sendmsg_locked:
        ffffffff91461d91 tcp_sendmsg_locked+0x1
        ffffffff91462b57 tcp_sendmsg+0x27
        ffffffff9139814e sock_sendmsg+0x3e
        ffffffffc06dfe1d smb_send_kvec+0x28
        [...]
        ffffffffc06cfaf8 cifs_readpages+0x213
        ffffffff90e83c4b read_pages+0x6b
        ffffffff90e83f31 __do_page_cache_readahead+0x1c1
        ffffffff90e79e98 filemap_fault+0x788
        ffffffff90eb0458 __do_fault+0x38
        ffffffff90eb5280 do_fault+0x1a0
        ffffffff90eb7c84 __handle_mm_fault+0x4d4
        f…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2021-47544</guid>
    </item>
  </channel>
</rss>
