<?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 13:37:23 +0000</lastBuildDate>
    <item>
      <title>bdu:2024-01590</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2024-01590</link>
      <description>bdu:2024-01590</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2024-01590</guid>
    </item>
    <item>
      <title>BELL-CVE-2023-52444</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2023-52444</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-2023-52444</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0226 — De multiples vulnérabilités ont été découvertes dans &lt;span
class="textit"&gt;le noyau Linux d'Ubuntu&lt;/span&gt;. Certaines d'e…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0226</link>
      <description>certfr-2024-avi-0226</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0226</guid>
    </item>
    <item>
      <title>EUVD-2026-344991</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-344991</link>
      <description>EUVD-2026-344991</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-344991</guid>
    </item>
    <item>
      <title>fkie_cve-2023-52444</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-52444</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;f2fs: fix to avoid dirent corruption&lt;/p&gt;
&lt;p&gt;As Al reported in link[1]:&lt;/p&gt;
&lt;p&gt;f2fs_rename()
...
	if (old_dir != new_dir &amp;amp;&amp;amp; !whiteout)
		f2fs_set_link(old_inode, old_dir_entry,
					old_dir_page, new_dir);
	else
		f2fs_put_page(old_dir_page, 0);&lt;/p&gt;
&lt;p&gt;You want correct inumber in the &amp;#34;..&amp;#34; link.  And cross-directory
rename does move the source to new parent, even if you&amp;#39;d been asked
to leave a whiteout in the old place.&lt;/p&gt;
&lt;p&gt;[1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/&lt;/p&gt;
&lt;p&gt;With below testcase, it may cause dirent corruption, due to it missed
to call f2fs_set_link() to update &amp;#34;..&amp;#34; link to new directory.
- mkdir -p dir/foo
- renameat2 -w dir/foo bar&lt;/p&gt;
&lt;p&gt;[ASSERT] (__chk_dots_dentries:1421)  --&amp;gt; Bad inode number[0x4] for &amp;#39;..&amp;#39;, parent parent ino is [0x3]
[FSCK] other corrupted bugs                           [Fail]&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;f2fs: fix to avoid dirent corruption&lt;/p&gt;
&lt;p&gt;As Al reported in link[1]:&lt;/p&gt;
&lt;p&gt;f2fs_rename()
...
	if (old_dir != new_dir &amp;amp;&amp;amp; !whiteout)
		f2fs_set_link(old_inode, old_dir_entry,
					old_dir_page, new_dir);
	else
		f2fs_put_page(old_dir_page, 0);&lt;/p&gt;
&lt;p&gt;You want correct inumber in the &amp;#34;..&amp;#34; link.  And cross-directory
rename does move the source to new parent, even if you&amp;#39;d been asked
to leave a whiteout in the old place.&lt;/p&gt;
&lt;p&gt;[1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/&lt;/p&gt;
&lt;p&gt;With below testcase, it may cause dirent corruption, due to it missed
to call f2fs_set_link() to update &amp;#34;..&amp;#34; link to new directory.
- mkdir -p dir/foo
- renameat2 -w dir/foo bar&lt;/p&gt;
&lt;p&gt;[ASSERT] (__chk_dots_dentries:1421)  --&amp;gt; Bad inode number[0x4] for &amp;#39;..&amp;#39;, parent parent ino is [0x3]
[FSCK] other corrupted bugs                           [Fail]&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-52444</guid>
    </item>
    <item>
      <title>GHSA-6f72-79f8-3qcp</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-6f72-79f8-3qcp</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;f2fs: fix to avoid dirent corruption&lt;/p&gt;
&lt;p&gt;As Al reported in link[1]:&lt;/p&gt;
&lt;p&gt;f2fs_rename()
...
	if (old_dir != new_dir &amp;amp;&amp;amp; !whiteout)
		f2fs_set_link(old_inode, old_dir_entry,
					old_dir_page, new_dir);
	else
		f2fs_put_page(old_dir_page, 0);&lt;/p&gt;
&lt;p&gt;You want correct inumber in the &amp;#34;..&amp;#34; link.  And cross-directory
rename does move the source to new parent, even if you&amp;#39;d been asked
to leave a whiteout in the old place.&lt;/p&gt;
&lt;p&gt;[1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/&lt;/p&gt;
&lt;p&gt;With below testcase, it may cause dirent corruption, due to it missed
to call f2fs_set_link() to update &amp;#34;..&amp;#34; link to new directory.
- mkdir -p dir/foo
- renameat2 -w dir/foo bar&lt;/p&gt;
&lt;p&gt;[ASSERT] (__chk_dots_dentries:1421)  --&amp;gt; Bad inode number[0x4] for &amp;#39;..&amp;#39;, parent parent ino is [0x3]
[FSCK] other corrupted bugs                           [Fail]&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;f2fs: fix to avoid dirent corruption&lt;/p&gt;
&lt;p&gt;As Al reported in link[1]:&lt;/p&gt;
&lt;p&gt;f2fs_rename()
...
	if (old_dir != new_dir &amp;amp;&amp;amp; !whiteout)
		f2fs_set_link(old_inode, old_dir_entry,
					old_dir_page, new_dir);
	else
		f2fs_put_page(old_dir_page, 0);&lt;/p&gt;
&lt;p&gt;You want correct inumber in the &amp;#34;..&amp;#34; link.  And cross-directory
rename does move the source to new parent, even if you&amp;#39;d been asked
to leave a whiteout in the old place.&lt;/p&gt;
&lt;p&gt;[1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/&lt;/p&gt;
&lt;p&gt;With below testcase, it may cause dirent corruption, due to it missed
to call f2fs_set_link() to update &amp;#34;..&amp;#34; link to new directory.
- mkdir -p dir/foo
- renameat2 -w dir/foo bar&lt;/p&gt;
&lt;p&gt;[ASSERT] (__chk_dots_dentries:1421)  --&amp;gt; Bad inode number[0x4] for &amp;#39;..&amp;#39;, parent parent ino is [0x3]
[FSCK] other corrupted bugs                           [Fail]&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-6f72-79f8-3qcp</guid>
    </item>
    <item>
      <title>gsd-2023-52444</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2023-52444</link>
      <description>gsd-2023-52444</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2023-52444</guid>
    </item>
    <item>
      <title>ICSA-23-348-10 — Siemens SIMATIC S7-1500</title>
      <link>https://cve.radiocsirt.org/vuln/icsa-23-348-10</link>
      <description>&lt;p&gt;expat 2.1.0 and earlier does not properly handle entities expansion unless an application developer uses the XML_SetEntityDeclHandler function, which allows remote attackers to cause a denial of service (resource consumption), send HTTP requests to intranet servers, or read arbitrary files via a crafted XML document, aka an XML External Entity (XXE) issue.  NOTE: it could be argued that because expat already provides the ability to disable external entity expansion, the responsibility for resolving this issue lies with application developers; according to this argument, this entry should be REJECTed, and each affected application would need its own CVE. shadow: TOCTOU (time-of-check time-of-use) race condition when copying and removing directory trees run-mailcap in the Debian mime-support package before 3.52-1+deb7u1 allows context-dependent attackers to execute arbitrary commands via shell metacharacters in a filename. In Python (aka CPython) up to 3.10.8, the mailcap module does not add escape characters into commands discovered in the system mailcap file. This may allow attackers to inject shell commands into applications that call mailcap.findmatch with untrusted input (if they lack validation of user-provided filenames or arguments). The fix is also back-ported to 3.7, 3.8, 3.9 Use-after-free vulnerability in bzip2recover in bzip2 1.0.6 allows remote attackers to cause a denial of service (crash) via a crafted bzip2 file, related to block ends set to before the start o…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;expat 2.1.0 and earlier does not properly handle entities expansion unless an application developer uses the XML_SetEntityDeclHandler function, which allows remote attackers to cause a denial of service (resource consumption), send HTTP requests to intranet servers, or read arbitrary files via a crafted XML document, aka an XML External Entity (XXE) issue.  NOTE: it could be argued that because expat already provides the ability to disable external entity expansion, the responsibility for resolving this issue lies with application developers; according to this argument, this entry should be REJECTed, and each affected application would need its own CVE. shadow: TOCTOU (time-of-check time-of-use) race condition when copying and removing directory trees run-mailcap in the Debian mime-support package before 3.52-1+deb7u1 allows context-dependent attackers to execute arbitrary commands via shell metacharacters in a filename. In Python (aka CPython) up to 3.10.8, the mailcap module does not add escape characters into commands discovered in the system mailcap file. This may allow attackers to inject shell commands into applications that call mailcap.findmatch with untrusted input (if they lack validation of user-provided filenames or arguments). The fix is also back-ported to 3.7, 3.8, 3.9 Use-after-free vulnerability in bzip2recover in bzip2 1.0.6 allows remote attackers to cause a denial of service (crash) via a crafted bzip2 file, related to block ends set to before the start o…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/icsa-23-348-10</guid>
    </item>
    <item>
      <title>OESA-2024-2255 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-2255</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
drm/i915/gt: Cleanup partial engine discovery failures&#13;
&#13;
If we abort driver initialisation in the middle of gt/engine discovery,
some engines will be fully setup and some not. Those incompletely setup
engines only have &amp;amp;apos;engine-&amp;amp;gt;release == NULL&amp;amp;apos; and so will leak any of the
common objects allocated.&#13;
&#13;
v2:
 - Drop the destroy_pinned_context() helper for now.  It&amp;amp;apos;s not really
   worth it with just a single callsite at the moment.  (Janusz)(CVE-2022-48893)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
f2fs: fix to avoid dirent corruption&#13;
&#13;
As Al reported in link[1]:&#13;
&#13;
f2fs_rename()
...
	if (old_dir != new_dir &amp;amp;amp;&amp;amp;amp; !whiteout)
		f2fs_set_link(old_inode, old_dir_entry,
					old_dir_page, new_dir);
	else
		f2fs_put_page(old_dir_page, 0);&#13;
&#13;
You want correct inumber in the &amp;amp;quot;..&amp;amp;quot; link.  And cross-directory
rename does move the source to new parent, even if you&amp;amp;apos;d been asked
to leave a whiteout in the old place.&#13;
&#13;
[1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/&#13;
&#13;
With below testcase, it may cause dirent corruption, due to it missed
to call f2fs_set_link() to update &amp;amp;quot;..&amp;amp;quot; link to new directory.
- mkdir -p dir/foo
- renameat2 -w dir/foo bar&#13;
&#13;
[ASSERT] (__chk_dots_dentries:1421)  --&amp;amp;gt; Bad inode number[0x4] for &amp;amp;apos;..&amp;amp;apos;, parent parent ino is [0…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
drm/i915/gt: Cleanup partial engine discovery failures&#13;
&#13;
If we abort driver initialisation in the middle of gt/engine discovery,
some engines will be fully setup and some not. Those incompletely setup
engines only have &amp;amp;apos;engine-&amp;amp;gt;release == NULL&amp;amp;apos; and so will leak any of the
common objects allocated.&#13;
&#13;
v2:
 - Drop the destroy_pinned_context() helper for now.  It&amp;amp;apos;s not really
   worth it with just a single callsite at the moment.  (Janusz)(CVE-2022-48893)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
f2fs: fix to avoid dirent corruption&#13;
&#13;
As Al reported in link[1]:&#13;
&#13;
f2fs_rename()
...
	if (old_dir != new_dir &amp;amp;amp;&amp;amp;amp; !whiteout)
		f2fs_set_link(old_inode, old_dir_entry,
					old_dir_page, new_dir);
	else
		f2fs_put_page(old_dir_page, 0);&#13;
&#13;
You want correct inumber in the &amp;amp;quot;..&amp;amp;quot; link.  And cross-directory
rename does move the source to new parent, even if you&amp;amp;apos;d been asked
to leave a whiteout in the old place.&#13;
&#13;
[1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/&#13;
&#13;
With below testcase, it may cause dirent corruption, due to it missed
to call f2fs_set_link() to update &amp;amp;quot;..&amp;amp;quot; link to new directory.
- mkdir -p dir/foo
- renameat2 -w dir/foo bar&#13;
&#13;
[ASSERT] (__chk_dots_dentries:1421)  --&amp;amp;gt; Bad inode number[0x4] for &amp;amp;apos;..&amp;amp;apos;, parent parent ino is [0…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-2255</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-52444</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-52444</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:Pro:16.04:LTS: linux-kvm and 158 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid dirent corruption As Al reported in link[1]: f2fs_rename() ... 	if (old_dir != new_dir &amp;amp;&amp;amp; !whiteout) 		f2fs_set_link(old_inode, old_dir_entry, 					old_dir_page, new_dir); 	else 		f2fs_put_page(old_dir_page, 0); You want correct inumber in the &amp;#34;..&amp;#34; link.  And cross-directory rename does move the source to new parent, even if you&amp;#39;d been asked to leave a whiteout in the old place. [1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/ With below testcase, it may cause dirent corruption, due to it missed to call f2fs_set_link() to update &amp;#34;..&amp;#34; link to new directory. - mkdir -p dir/foo - renameat2 -w dir/foo bar [ASSERT] (__chk_dots_dentries:1421)  --&amp;gt; Bad inode number[0x4] for &amp;#39;..&amp;#39;, parent parent ino is [0x3] [FSCK] other corrupted bugs                           [Fail]&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:Pro:16.04:LTS: linux-kvm and 158 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid dirent corruption As Al reported in link[1]: f2fs_rename() ... 	if (old_dir != new_dir &amp;amp;&amp;amp; !whiteout) 		f2fs_set_link(old_inode, old_dir_entry, 					old_dir_page, new_dir); 	else 		f2fs_put_page(old_dir_page, 0); You want correct inumber in the &amp;#34;..&amp;#34; link.  And cross-directory rename does move the source to new parent, even if you&amp;#39;d been asked to leave a whiteout in the old place. [1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/ With below testcase, it may cause dirent corruption, due to it missed to call f2fs_set_link() to update &amp;#34;..&amp;#34; link to new directory. - mkdir -p dir/foo - renameat2 -w dir/foo bar [ASSERT] (__chk_dots_dentries:1421)  --&amp;gt; Bad inode number[0x4] for &amp;#39;..&amp;#39;, parent parent ino is [0x3] [FSCK] other corrupted bugs                           [Fail]&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-52444</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-0473 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0473</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand herbeizuführen oder einen nicht spezifizierten Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand herbeizuführen oder einen nicht spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0473</guid>
    </item>
  </channel>
</rss>
