<?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>Sat, 03 Oct 2026 16:02:38 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-72196</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-72196</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-72196</guid>
    </item>
    <item>
      <title>EUVD-2026-353971</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-353971</link>
      <description>EUVD-2026-353971</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-353971</guid>
    </item>
    <item>
      <title>fkie_cve-2026-72196</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-72196</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs/ntfs3: bound copy_lcns dp-&amp;gt;page_lcns[] index in analysis pass&lt;/p&gt;
&lt;p&gt;In log_replay()&amp;#39;s analysis pass, after find_dp() returns a
valid DIR_PAGE_ENTRY for the (target_attr, target_vcn) tuple,
the copy_lcns block walks lrh-&amp;gt;lcns_follow further entries:&lt;/p&gt;
&lt;p&gt;t16 = le16_to_cpu(lrh-&amp;gt;lcns_follow);
	for (i = 0; i &amp;lt; t16; i++) {
	    size_t j = (size_t)(le64_to_cpu(lrh-&amp;gt;target_vcn) -
	                        le64_to_cpu(dp-&amp;gt;vcn));
	    dp-&amp;gt;page_lcns[j + i] = lrh-&amp;gt;page_lcns[i];
	}&lt;/p&gt;
&lt;p&gt;find_dp() only validates that target_vcn falls within
[dp-&amp;gt;vcn, dp-&amp;gt;vcn + dp-&amp;gt;lcns_follow), i.e., that the FIRST
cluster is covered.  The walk through the further entries is
not bounded against dp-&amp;gt;lcns_follow.  For a malformed LRH
where target_vcn = dp-&amp;gt;vcn + dp-&amp;gt;lcns_follow - 1 and
lrh-&amp;gt;lcns_follow &amp;gt; 1, the i &amp;gt; 0 writes overflow the dp&amp;#39;s
allocated page_lcns[] array.&lt;/p&gt;
&lt;p&gt;Add the missing j + lrh-&amp;gt;lcns_follow &amp;lt;= dp-&amp;gt;lcns_follow guard.&lt;/p&gt;
&lt;p&gt;Reproduced under UML+KASAN on mainline 8d90b09e6741 as a
slab-out-of-bounds write of size 8 from log_replay+0x68d4 on
the mount path.&lt;/p&gt;
&lt;p&gt;This is distinct from Pavitra Jha&amp;#39;s 2026-05-02 patch
(&amp;#34;fs/ntfs3: validate lcns_follow in log_replay conversion&amp;#34;,
&amp;lt;20260502154252.164586-1-jhapavitra98@gmail.com&amp;gt;) which
addresses the separate version-0 dirty-page-table conversion
path&amp;#39;s memmove(&amp;amp;dp-&amp;gt;vcn, ...) call.  The two fixes are
complementary; both should land.&lt;/p&gt;
&lt;p&gt;[almaz.alexandrovich@paragon-software.com: clang-formatted the changes…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs/ntfs3: bound copy_lcns dp-&amp;gt;page_lcns[] index in analysis pass&lt;/p&gt;
&lt;p&gt;In log_replay()&amp;#39;s analysis pass, after find_dp() returns a
valid DIR_PAGE_ENTRY for the (target_attr, target_vcn) tuple,
the copy_lcns block walks lrh-&amp;gt;lcns_follow further entries:&lt;/p&gt;
&lt;p&gt;t16 = le16_to_cpu(lrh-&amp;gt;lcns_follow);
	for (i = 0; i &amp;lt; t16; i++) {
	    size_t j = (size_t)(le64_to_cpu(lrh-&amp;gt;target_vcn) -
	                        le64_to_cpu(dp-&amp;gt;vcn));
	    dp-&amp;gt;page_lcns[j + i] = lrh-&amp;gt;page_lcns[i];
	}&lt;/p&gt;
&lt;p&gt;find_dp() only validates that target_vcn falls within
[dp-&amp;gt;vcn, dp-&amp;gt;vcn + dp-&amp;gt;lcns_follow), i.e., that the FIRST
cluster is covered.  The walk through the further entries is
not bounded against dp-&amp;gt;lcns_follow.  For a malformed LRH
where target_vcn = dp-&amp;gt;vcn + dp-&amp;gt;lcns_follow - 1 and
lrh-&amp;gt;lcns_follow &amp;gt; 1, the i &amp;gt; 0 writes overflow the dp&amp;#39;s
allocated page_lcns[] array.&lt;/p&gt;
&lt;p&gt;Add the missing j + lrh-&amp;gt;lcns_follow &amp;lt;= dp-&amp;gt;lcns_follow guard.&lt;/p&gt;
&lt;p&gt;Reproduced under UML+KASAN on mainline 8d90b09e6741 as a
slab-out-of-bounds write of size 8 from log_replay+0x68d4 on
the mount path.&lt;/p&gt;
&lt;p&gt;This is distinct from Pavitra Jha&amp;#39;s 2026-05-02 patch
(&amp;#34;fs/ntfs3: validate lcns_follow in log_replay conversion&amp;#34;,
&amp;lt;20260502154252.164586-1-jhapavitra98@gmail.com&amp;gt;) which
addresses the separate version-0 dirty-page-table conversion
path&amp;#39;s memmove(&amp;amp;dp-&amp;gt;vcn, ...) call.  The two fixes are
complementary; both should land.&lt;/p&gt;
&lt;p&gt;[almaz.alexandrovich@paragon-software.com: clang-formatted the changes…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-72196</guid>
    </item>
    <item>
      <title>GHSA-7v7p-59m6-6h9x</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-7v7p-59m6-6h9x</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs/ntfs3: bound copy_lcns dp-&amp;gt;page_lcns[] index in analysis pass&lt;/p&gt;
&lt;p&gt;In log_replay()&amp;#39;s analysis pass, after find_dp() returns a
valid DIR_PAGE_ENTRY for the (target_attr, target_vcn) tuple,
the copy_lcns block walks lrh-&amp;gt;lcns_follow further entries:&lt;/p&gt;
&lt;p&gt;t16 = le16_to_cpu(lrh-&amp;gt;lcns_follow);
	for (i = 0; i &amp;lt; t16; i++) {
	    size_t j = (size_t)(le64_to_cpu(lrh-&amp;gt;target_vcn) -
	                        le64_to_cpu(dp-&amp;gt;vcn));
	    dp-&amp;gt;page_lcns[j + i] = lrh-&amp;gt;page_lcns[i];
	}&lt;/p&gt;
&lt;p&gt;find_dp() only validates that target_vcn falls within
[dp-&amp;gt;vcn, dp-&amp;gt;vcn + dp-&amp;gt;lcns_follow), i.e., that the FIRST
cluster is covered.  The walk through the further entries is
not bounded against dp-&amp;gt;lcns_follow.  For a malformed LRH
where target_vcn = dp-&amp;gt;vcn + dp-&amp;gt;lcns_follow - 1 and
lrh-&amp;gt;lcns_follow &amp;gt; 1, the i &amp;gt; 0 writes overflow the dp&amp;#39;s
allocated page_lcns[] array.&lt;/p&gt;
&lt;p&gt;Add the missing j + lrh-&amp;gt;lcns_follow &amp;lt;= dp-&amp;gt;lcns_follow guard.&lt;/p&gt;
&lt;p&gt;Reproduced under UML+KASAN on mainline 8d90b09e6741 as a
slab-out-of-bounds write of size 8 from log_replay+0x68d4 on
the mount path.&lt;/p&gt;
&lt;p&gt;This is distinct from Pavitra Jha&amp;#39;s 2026-05-02 patch
(&amp;#34;fs/ntfs3: validate lcns_follow in log_replay conversion&amp;#34;,
&amp;lt;20260502154252.164586-1-jhapavitra98@gmail.com&amp;gt;) which
addresses the separate version-0 dirty-page-table conversion
path&amp;#39;s memmove(&amp;amp;dp-&amp;gt;vcn, ...) call.  The two fixes are
complementary; both should land.&lt;/p&gt;
&lt;p&gt;[almaz.alexandrovich@paragon-software.com: clang-formatted the changes…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs/ntfs3: bound copy_lcns dp-&amp;gt;page_lcns[] index in analysis pass&lt;/p&gt;
&lt;p&gt;In log_replay()&amp;#39;s analysis pass, after find_dp() returns a
valid DIR_PAGE_ENTRY for the (target_attr, target_vcn) tuple,
the copy_lcns block walks lrh-&amp;gt;lcns_follow further entries:&lt;/p&gt;
&lt;p&gt;t16 = le16_to_cpu(lrh-&amp;gt;lcns_follow);
	for (i = 0; i &amp;lt; t16; i++) {
	    size_t j = (size_t)(le64_to_cpu(lrh-&amp;gt;target_vcn) -
	                        le64_to_cpu(dp-&amp;gt;vcn));
	    dp-&amp;gt;page_lcns[j + i] = lrh-&amp;gt;page_lcns[i];
	}&lt;/p&gt;
&lt;p&gt;find_dp() only validates that target_vcn falls within
[dp-&amp;gt;vcn, dp-&amp;gt;vcn + dp-&amp;gt;lcns_follow), i.e., that the FIRST
cluster is covered.  The walk through the further entries is
not bounded against dp-&amp;gt;lcns_follow.  For a malformed LRH
where target_vcn = dp-&amp;gt;vcn + dp-&amp;gt;lcns_follow - 1 and
lrh-&amp;gt;lcns_follow &amp;gt; 1, the i &amp;gt; 0 writes overflow the dp&amp;#39;s
allocated page_lcns[] array.&lt;/p&gt;
&lt;p&gt;Add the missing j + lrh-&amp;gt;lcns_follow &amp;lt;= dp-&amp;gt;lcns_follow guard.&lt;/p&gt;
&lt;p&gt;Reproduced under UML+KASAN on mainline 8d90b09e6741 as a
slab-out-of-bounds write of size 8 from log_replay+0x68d4 on
the mount path.&lt;/p&gt;
&lt;p&gt;This is distinct from Pavitra Jha&amp;#39;s 2026-05-02 patch
(&amp;#34;fs/ntfs3: validate lcns_follow in log_replay conversion&amp;#34;,
&amp;lt;20260502154252.164586-1-jhapavitra98@gmail.com&amp;gt;) which
addresses the separate version-0 dirty-page-table conversion
path&amp;#39;s memmove(&amp;amp;dp-&amp;gt;vcn, ...) call.  The two fixes are
complementary; both should land.&lt;/p&gt;
&lt;p&gt;[almaz.alexandrovich@paragon-software.com: clang-formatted the changes…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-7v7p-59m6-6h9x</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-72196</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-72196</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 193 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound copy_lcns dp-&amp;gt;page_lcns[] index in analysis pass In log_replay()&amp;#39;s analysis pass, after find_dp() returns a valid DIR_PAGE_ENTRY for the (target_attr, target_vcn) tuple, the copy_lcns block walks lrh-&amp;gt;lcns_follow further entries: 	t16 = le16_to_cpu(lrh-&amp;gt;lcns_follow); 	for (i = 0; i &amp;lt; t16; i++) { 	    size_t j = (size_t)(le64_to_cpu(lrh-&amp;gt;target_vcn) - 	                        le64_to_cpu(dp-&amp;gt;vcn)); 	    dp-&amp;gt;page_lcns[j + i] = lrh-&amp;gt;page_lcns[i]; 	} find_dp() only validates that target_vcn falls within [dp-&amp;gt;vcn, dp-&amp;gt;vcn + dp-&amp;gt;lcns_follow), i.e., that the FIRST cluster is covered.  The walk through the further entries is not bounded against dp-&amp;gt;lcns_follow.  For a malformed LRH where target_vcn = dp-&amp;gt;vcn + dp-&amp;gt;lcns_follow - 1 and lrh-&amp;gt;lcns_follow &amp;gt; 1, the i &amp;gt; 0 writes overflow the dp&amp;#39;s allocated page_lcns[] array. Add the missing j + lrh-&amp;gt;lcns_follow &amp;lt;= dp-&amp;gt;lcns_follow guard. Reproduced under UML+KASAN on mainline 8d90b09e6741 as a slab-out-of-bounds write of size 8 from log_replay+0x68d4 on the mount path. This is distinct from Pavitra Jha&amp;#39;s 2026-05-02 patch (&amp;#34;fs/ntfs3: validate lcns_follow in log_replay conversion&amp;#34;, &amp;lt;20260502154252.164586-1-jhapavitra98@gmail.com&amp;gt;) which addresses the separate version-0 dirty-page-table conversion path&amp;#39;s memmove(&amp;amp;dp-&amp;gt;vcn, ...) call.  The two fixes are complementary; both should land. [almaz.alexandrovich@paragon-software.com: clang-formatted the changes, fixed…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 193 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound copy_lcns dp-&amp;gt;page_lcns[] index in analysis pass In log_replay()&amp;#39;s analysis pass, after find_dp() returns a valid DIR_PAGE_ENTRY for the (target_attr, target_vcn) tuple, the copy_lcns block walks lrh-&amp;gt;lcns_follow further entries: 	t16 = le16_to_cpu(lrh-&amp;gt;lcns_follow); 	for (i = 0; i &amp;lt; t16; i++) { 	    size_t j = (size_t)(le64_to_cpu(lrh-&amp;gt;target_vcn) - 	                        le64_to_cpu(dp-&amp;gt;vcn)); 	    dp-&amp;gt;page_lcns[j + i] = lrh-&amp;gt;page_lcns[i]; 	} find_dp() only validates that target_vcn falls within [dp-&amp;gt;vcn, dp-&amp;gt;vcn + dp-&amp;gt;lcns_follow), i.e., that the FIRST cluster is covered.  The walk through the further entries is not bounded against dp-&amp;gt;lcns_follow.  For a malformed LRH where target_vcn = dp-&amp;gt;vcn + dp-&amp;gt;lcns_follow - 1 and lrh-&amp;gt;lcns_follow &amp;gt; 1, the i &amp;gt; 0 writes overflow the dp&amp;#39;s allocated page_lcns[] array. Add the missing j + lrh-&amp;gt;lcns_follow &amp;lt;= dp-&amp;gt;lcns_follow guard. Reproduced under UML+KASAN on mainline 8d90b09e6741 as a slab-out-of-bounds write of size 8 from log_replay+0x68d4 on the mount path. This is distinct from Pavitra Jha&amp;#39;s 2026-05-02 patch (&amp;#34;fs/ntfs3: validate lcns_follow in log_replay conversion&amp;#34;, &amp;lt;20260502154252.164586-1-jhapavitra98@gmail.com&amp;gt;) which addresses the separate version-0 dirty-page-table conversion path&amp;#39;s memmove(&amp;amp;dp-&amp;gt;vcn, ...) call.  The two fixes are complementary; both should land. [almaz.alexandrovich@paragon-software.com: clang-formatted the changes, fixed…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-72196</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2852 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2852</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um root Rechte zu erlangen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um root Rechte zu erlangen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2852</guid>
    </item>
  </channel>
</rss>
