<?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 22:34:19 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-11699</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-11699</link>
      <description>bdu:2026-11699</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-11699</guid>
    </item>
    <item>
      <title>BELL-CVE-2026-43187</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-43187</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-43187</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0696 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Certaines d'entre elles permettent à…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0696</link>
      <description>certfr-2026-avi-0696</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0696</guid>
    </item>
    <item>
      <title>EUVD-2026-347851</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-347851</link>
      <description>EUVD-2026-347851</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-347851</guid>
    </item>
    <item>
      <title>fkie_cve-2026-43187</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-43187</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;xfs: delete attr leaf freemap entries when empty&lt;/p&gt;
&lt;p&gt;Back in commit 2a2b5932db6758 (&amp;#34;xfs: fix attr leaf header freemap.size
underflow&amp;#34;), Brian Foster observed that it&amp;#39;s possible for a small
freemap at the end of the end of the xattr entries array to experience
a size underflow when subtracting the space consumed by an expansion of
the entries array.  There are only three freemap entries, which means
that it is not a complete index of all free space in the leaf block.&lt;/p&gt;
&lt;p&gt;This code can leave behind a zero-length freemap entry with a nonzero
base.  Subsequent setxattr operations can increase the base up to the
point that it overlaps with another freemap entry.  This isn&amp;#39;t in and of
itself a problem because the code in _leaf_add that finds free space
ignores any freemap entry with zero size.&lt;/p&gt;
&lt;p&gt;However, there&amp;#39;s another bug in the freemap update code in _leaf_add,
which is that it fails to update a freemap entry that begins midway
through the xattr entry that was just appended to the array.  That can
result in the freemap containing two entries with the same base but
different sizes (0 for the &amp;#34;pushed-up&amp;#34; entry, nonzero for the entry
that&amp;#39;s actually tracking free space).  A subsequent _leaf_add can then
allocate xattr namevalue entries on top of the entries array, leading to
data loss.  But fixing that is for later.&lt;/p&gt;
&lt;p&gt;For now, eliminate the possibility of confusion by zeroing out the base
of any freemap entry that has z…&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;xfs: delete attr leaf freemap entries when empty&lt;/p&gt;
&lt;p&gt;Back in commit 2a2b5932db6758 (&amp;#34;xfs: fix attr leaf header freemap.size
underflow&amp;#34;), Brian Foster observed that it&amp;#39;s possible for a small
freemap at the end of the end of the xattr entries array to experience
a size underflow when subtracting the space consumed by an expansion of
the entries array.  There are only three freemap entries, which means
that it is not a complete index of all free space in the leaf block.&lt;/p&gt;
&lt;p&gt;This code can leave behind a zero-length freemap entry with a nonzero
base.  Subsequent setxattr operations can increase the base up to the
point that it overlaps with another freemap entry.  This isn&amp;#39;t in and of
itself a problem because the code in _leaf_add that finds free space
ignores any freemap entry with zero size.&lt;/p&gt;
&lt;p&gt;However, there&amp;#39;s another bug in the freemap update code in _leaf_add,
which is that it fails to update a freemap entry that begins midway
through the xattr entry that was just appended to the array.  That can
result in the freemap containing two entries with the same base but
different sizes (0 for the &amp;#34;pushed-up&amp;#34; entry, nonzero for the entry
that&amp;#39;s actually tracking free space).  A subsequent _leaf_add can then
allocate xattr namevalue entries on top of the entries array, leading to
data loss.  But fixing that is for later.&lt;/p&gt;
&lt;p&gt;For now, eliminate the possibility of confusion by zeroing out the base
of any freemap entry that has z…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-43187</guid>
    </item>
    <item>
      <title>GHSA-8h5h-g93f-3ff6</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-8h5h-g93f-3ff6</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;xfs: delete attr leaf freemap entries when empty&lt;/p&gt;
&lt;p&gt;Back in commit 2a2b5932db6758 (&amp;#34;xfs: fix attr leaf header freemap.size
underflow&amp;#34;), Brian Foster observed that it&amp;#39;s possible for a small
freemap at the end of the end of the xattr entries array to experience
a size underflow when subtracting the space consumed by an expansion of
the entries array.  There are only three freemap entries, which means
that it is not a complete index of all free space in the leaf block.&lt;/p&gt;
&lt;p&gt;This code can leave behind a zero-length freemap entry with a nonzero
base.  Subsequent setxattr operations can increase the base up to the
point that it overlaps with another freemap entry.  This isn&amp;#39;t in and of
itself a problem because the code in _leaf_add that finds free space
ignores any freemap entry with zero size.&lt;/p&gt;
&lt;p&gt;However, there&amp;#39;s another bug in the freemap update code in _leaf_add,
which is that it fails to update a freemap entry that begins midway
through the xattr entry that was just appended to the array.  That can
result in the freemap containing two entries with the same base but
different sizes (0 for the &amp;#34;pushed-up&amp;#34; entry, nonzero for the entry
that&amp;#39;s actually tracking free space).  A subsequent _leaf_add can then
allocate xattr namevalue entries on top of the entries array, leading to
data loss.  But fixing that is for later.&lt;/p&gt;
&lt;p&gt;For now, eliminate the possibility of confusion by zeroing out the base
of any freemap entry that has z…&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;xfs: delete attr leaf freemap entries when empty&lt;/p&gt;
&lt;p&gt;Back in commit 2a2b5932db6758 (&amp;#34;xfs: fix attr leaf header freemap.size
underflow&amp;#34;), Brian Foster observed that it&amp;#39;s possible for a small
freemap at the end of the end of the xattr entries array to experience
a size underflow when subtracting the space consumed by an expansion of
the entries array.  There are only three freemap entries, which means
that it is not a complete index of all free space in the leaf block.&lt;/p&gt;
&lt;p&gt;This code can leave behind a zero-length freemap entry with a nonzero
base.  Subsequent setxattr operations can increase the base up to the
point that it overlaps with another freemap entry.  This isn&amp;#39;t in and of
itself a problem because the code in _leaf_add that finds free space
ignores any freemap entry with zero size.&lt;/p&gt;
&lt;p&gt;However, there&amp;#39;s another bug in the freemap update code in _leaf_add,
which is that it fails to update a freemap entry that begins midway
through the xattr entry that was just appended to the array.  That can
result in the freemap containing two entries with the same base but
different sizes (0 for the &amp;#34;pushed-up&amp;#34; entry, nonzero for the entry
that&amp;#39;s actually tracking free space).  A subsequent _leaf_add can then
allocate xattr namevalue entries on top of the entries array, leading to
data loss.  But fixing that is for later.&lt;/p&gt;
&lt;p&gt;For now, eliminate the possibility of confusion by zeroing out the base
of any freemap entry that has z…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-8h5h-g93f-3ff6</guid>
    </item>
    <item>
      <title>OESA-2026-2754 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-2754</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fbdev: fix potential buffer overflow in do_register_framebuffer()&lt;/p&gt;
&lt;p&gt;The current implementation may lead to buffer overflow when:
1.  Unregistration creates NULL gaps in registered_fb[]
2.  All array slots become occupied despite num_registered_fb &amp;amp;lt; FB_MAX
3.  The registration loop exceeds array bounds&lt;/p&gt;
&lt;p&gt;Add boundary check to prevent registered_fb[FB_MAX] access.(CVE-2025-38702)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;hfs: validate record offset in hfsplus_bmap_alloc&lt;/p&gt;
&lt;p&gt;hfsplus_bmap_alloc can trigger a crash if a
record offset or length is larger than node_size&lt;/p&gt;
&lt;p&gt;[   15.264282] BUG: KASAN: slab-out-of-bounds in hfsplus_bmap_alloc+0x887/0x8b0
[   15.265192] Read of size 8 at addr ffff8881085ca188 by task test/183
[   15.265949]
[   15.266163] CPU: 0 UID: 0 PID: 183 Comm: test Not tainted 6.17.0-rc2-gc17b750b3ad9 #14 PREEMPT(voluntary)
[   15.266165] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[   15.266167] Call Trace:
[   15.266168]  &amp;amp;lt;TASK&amp;amp;gt;
[   15.266169]  dump_stack_lvl+0x53/0x70
[   15.266173]  print_report+0xd0/0x660
[   15.266181]  kasan_report+0xce/0x100
[   15.266185]  hfsplus_bmap_alloc+0x887/0x8b0
[   15.266208]  hfs_btree_inc_height.isra.0+0xd5/0x7c0
[   15.266217]  hfsplus_brec_insert+0x870/0xb00
[   15.266222]  __hfsplus_ext_write_extent+…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fbdev: fix potential buffer overflow in do_register_framebuffer()&lt;/p&gt;
&lt;p&gt;The current implementation may lead to buffer overflow when:
1.  Unregistration creates NULL gaps in registered_fb[]
2.  All array slots become occupied despite num_registered_fb &amp;amp;lt; FB_MAX
3.  The registration loop exceeds array bounds&lt;/p&gt;
&lt;p&gt;Add boundary check to prevent registered_fb[FB_MAX] access.(CVE-2025-38702)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;hfs: validate record offset in hfsplus_bmap_alloc&lt;/p&gt;
&lt;p&gt;hfsplus_bmap_alloc can trigger a crash if a
record offset or length is larger than node_size&lt;/p&gt;
&lt;p&gt;[   15.264282] BUG: KASAN: slab-out-of-bounds in hfsplus_bmap_alloc+0x887/0x8b0
[   15.265192] Read of size 8 at addr ffff8881085ca188 by task test/183
[   15.265949]
[   15.266163] CPU: 0 UID: 0 PID: 183 Comm: test Not tainted 6.17.0-rc2-gc17b750b3ad9 #14 PREEMPT(voluntary)
[   15.266165] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[   15.266167] Call Trace:
[   15.266168]  &amp;amp;lt;TASK&amp;amp;gt;
[   15.266169]  dump_stack_lvl+0x53/0x70
[   15.266173]  print_report+0xd0/0x660
[   15.266181]  kasan_report+0xce/0x100
[   15.266185]  hfsplus_bmap_alloc+0x887/0x8b0
[   15.266208]  hfs_btree_inc_height.isra.0+0xd5/0x7c0
[   15.266217]  hfsplus_brec_insert+0x870/0xb00
[   15.266222]  __hfsplus_ext_write_extent+…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-2754</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:21388-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:21388-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:21388-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:22433-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:22433-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2026:22433-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-43187</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-43187</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, 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 and 232 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: xfs: delete attr leaf freemap entries when empty Back in commit 2a2b5932db6758 (&amp;#34;xfs: fix attr leaf header freemap.size underflow&amp;#34;), Brian Foster observed that it&amp;#39;s possible for a small freemap at the end of the end of the xattr entries array to experience a size underflow when subtracting the space consumed by an expansion of the entries array.  There are only three freemap entries, which means that it is not a complete index of all free space in the leaf block. This code can leave behind a zero-length freemap entry with a nonzero base.  Subsequent setxattr operations can increase the base up to the point that it overlaps with another freemap entry.  This isn&amp;#39;t in and of itself a problem because the code in _leaf_add that finds free space ignores any freemap entry with zero size. However, there&amp;#39;s another bug in the freemap update code in _leaf_add, which is that it fails to update a freemap entry that begins midway through the xattr entry that was just appended to the array.  That can result in the freemap containing two entries with the same base but different sizes (0 for the &amp;#34;pushed-up&amp;#34; entry, nonzero for the entry that&amp;#39;s actually tracking free space).  A subsequent _leaf_add can then allocate xattr namevalue entries on top of the entries array, leading to data loss.  But fixing that is for later. For now, eliminate the possibility of confusion by zeroing out the base of any freemap entry that has zero s…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, 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 and 232 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: xfs: delete attr leaf freemap entries when empty Back in commit 2a2b5932db6758 (&amp;#34;xfs: fix attr leaf header freemap.size underflow&amp;#34;), Brian Foster observed that it&amp;#39;s possible for a small freemap at the end of the end of the xattr entries array to experience a size underflow when subtracting the space consumed by an expansion of the entries array.  There are only three freemap entries, which means that it is not a complete index of all free space in the leaf block. This code can leave behind a zero-length freemap entry with a nonzero base.  Subsequent setxattr operations can increase the base up to the point that it overlaps with another freemap entry.  This isn&amp;#39;t in and of itself a problem because the code in _leaf_add that finds free space ignores any freemap entry with zero size. However, there&amp;#39;s another bug in the freemap update code in _leaf_add, which is that it fails to update a freemap entry that begins midway through the xattr entry that was just appended to the array.  That can result in the freemap containing two entries with the same base but different sizes (0 for the &amp;#34;pushed-up&amp;#34; entry, nonzero for the entry that&amp;#39;s actually tracking free space).  A subsequent _leaf_add can then allocate xattr namevalue entries on top of the entries array, leading to data loss.  But fixing that is for later. For now, eliminate the possibility of confusion by zeroing out the base of any freemap entry that has zero s…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-43187</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1405 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1405</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht spezifizierte Angriffe durchzuführen, möglicherweise Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren oder offenzulegen oder einen Denial-of-Service-Zustand zu verursachen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht spezifizierte Angriffe durchzuführen, möglicherweise Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren oder offenzulegen oder einen Denial-of-Service-Zustand zu verursachen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1405</guid>
    </item>
  </channel>
</rss>
