<?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>Sun, 04 Oct 2026 01:03:07 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-31598</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-31598</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-31598</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0548 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Certaines d'entre elles permettent à un…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0548</link>
      <description>certfr-2026-avi-0548</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0548</guid>
    </item>
    <item>
      <title>EUVD-2026-347728</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-347728</link>
      <description>EUVD-2026-347728</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-347728</guid>
    </item>
    <item>
      <title>fkie_cve-2026-31598</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-31598</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ocfs2: fix possible deadlock between unlink and dio_end_io_write&lt;/p&gt;
&lt;p&gt;ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem,
while in ocfs2_dio_end_io_write, it acquires these locks in reverse order.
This creates an ABBA lock ordering violation on lock classes
ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and
ocfs2_file_ip_alloc_sem_key.&lt;/p&gt;
&lt;p&gt;Lock Chain #0 (orphan dir inode_lock -&amp;gt; ip_alloc_sem):
ocfs2_unlink
  ocfs2_prepare_orphan_dir
    ocfs2_lookup_lock_orphan_dir
      inode_lock(orphan_dir_inode) &amp;lt;- lock A
    __ocfs2_prepare_orphan_dir
      ocfs2_prepare_dir_for_insert
        ocfs2_extend_dir
	  ocfs2_expand_inline_dir
	    down_write(&amp;amp;oi-&amp;gt;ip_alloc_sem) &amp;lt;- Lock B&lt;/p&gt;
&lt;p&gt;Lock Chain #1 (ip_alloc_sem -&amp;gt; orphan dir inode_lock):
ocfs2_dio_end_io_write
  down_write(&amp;amp;oi-&amp;gt;ip_alloc_sem) &amp;lt;- Lock B
  ocfs2_del_inode_from_orphan()
    inode_lock(orphan_dir_inode) &amp;lt;- Lock A&lt;/p&gt;
&lt;p&gt;Deadlock Scenario:
  CPU0 (unlink)                     CPU1 (dio_end_io_write)
  ------                            ------
  inode_lock(orphan_dir_inode)
                                    down_write(ip_alloc_sem)
  down_write(ip_alloc_sem)
                                    inode_lock(orphan_dir_inode)&lt;/p&gt;
&lt;p&gt;Since ip_alloc_sem is to protect allocation changes, which is unrelated
with operations in ocfs2_del_inode_from_orphan.  So move
ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.&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;ocfs2: fix possible deadlock between unlink and dio_end_io_write&lt;/p&gt;
&lt;p&gt;ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem,
while in ocfs2_dio_end_io_write, it acquires these locks in reverse order.
This creates an ABBA lock ordering violation on lock classes
ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and
ocfs2_file_ip_alloc_sem_key.&lt;/p&gt;
&lt;p&gt;Lock Chain #0 (orphan dir inode_lock -&amp;gt; ip_alloc_sem):
ocfs2_unlink
  ocfs2_prepare_orphan_dir
    ocfs2_lookup_lock_orphan_dir
      inode_lock(orphan_dir_inode) &amp;lt;- lock A
    __ocfs2_prepare_orphan_dir
      ocfs2_prepare_dir_for_insert
        ocfs2_extend_dir
	  ocfs2_expand_inline_dir
	    down_write(&amp;amp;oi-&amp;gt;ip_alloc_sem) &amp;lt;- Lock B&lt;/p&gt;
&lt;p&gt;Lock Chain #1 (ip_alloc_sem -&amp;gt; orphan dir inode_lock):
ocfs2_dio_end_io_write
  down_write(&amp;amp;oi-&amp;gt;ip_alloc_sem) &amp;lt;- Lock B
  ocfs2_del_inode_from_orphan()
    inode_lock(orphan_dir_inode) &amp;lt;- Lock A&lt;/p&gt;
&lt;p&gt;Deadlock Scenario:
  CPU0 (unlink)                     CPU1 (dio_end_io_write)
  ------                            ------
  inode_lock(orphan_dir_inode)
                                    down_write(ip_alloc_sem)
  down_write(ip_alloc_sem)
                                    inode_lock(orphan_dir_inode)&lt;/p&gt;
&lt;p&gt;Since ip_alloc_sem is to protect allocation changes, which is unrelated
with operations in ocfs2_del_inode_from_orphan.  So move
ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-31598</guid>
    </item>
    <item>
      <title>GHSA-cqwh-r98h-2279</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-cqwh-r98h-2279</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ocfs2: fix possible deadlock between unlink and dio_end_io_write&lt;/p&gt;
&lt;p&gt;ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem,
while in ocfs2_dio_end_io_write, it acquires these locks in reverse order.
This creates an ABBA lock ordering violation on lock classes
ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and
ocfs2_file_ip_alloc_sem_key.&lt;/p&gt;
&lt;p&gt;Lock Chain #0 (orphan dir inode_lock -&amp;gt; ip_alloc_sem):
ocfs2_unlink
  ocfs2_prepare_orphan_dir
    ocfs2_lookup_lock_orphan_dir
      inode_lock(orphan_dir_inode) &amp;lt;- lock A
    __ocfs2_prepare_orphan_dir
      ocfs2_prepare_dir_for_insert
        ocfs2_extend_dir
	  ocfs2_expand_inline_dir
	    down_write(&amp;amp;oi-&amp;gt;ip_alloc_sem) &amp;lt;- Lock B&lt;/p&gt;
&lt;p&gt;Lock Chain #1 (ip_alloc_sem -&amp;gt; orphan dir inode_lock):
ocfs2_dio_end_io_write
  down_write(&amp;amp;oi-&amp;gt;ip_alloc_sem) &amp;lt;- Lock B
  ocfs2_del_inode_from_orphan()
    inode_lock(orphan_dir_inode) &amp;lt;- Lock A&lt;/p&gt;
&lt;p&gt;Deadlock Scenario:
  CPU0 (unlink)                     CPU1 (dio_end_io_write)
  ------                            ------
  inode_lock(orphan_dir_inode)
                                    down_write(ip_alloc_sem)
  down_write(ip_alloc_sem)
                                    inode_lock(orphan_dir_inode)&lt;/p&gt;
&lt;p&gt;Since ip_alloc_sem is to protect allocation changes, which is unrelated
with operations in ocfs2_del_inode_from_orphan.  So move
ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.&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;ocfs2: fix possible deadlock between unlink and dio_end_io_write&lt;/p&gt;
&lt;p&gt;ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem,
while in ocfs2_dio_end_io_write, it acquires these locks in reverse order.
This creates an ABBA lock ordering violation on lock classes
ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and
ocfs2_file_ip_alloc_sem_key.&lt;/p&gt;
&lt;p&gt;Lock Chain #0 (orphan dir inode_lock -&amp;gt; ip_alloc_sem):
ocfs2_unlink
  ocfs2_prepare_orphan_dir
    ocfs2_lookup_lock_orphan_dir
      inode_lock(orphan_dir_inode) &amp;lt;- lock A
    __ocfs2_prepare_orphan_dir
      ocfs2_prepare_dir_for_insert
        ocfs2_extend_dir
	  ocfs2_expand_inline_dir
	    down_write(&amp;amp;oi-&amp;gt;ip_alloc_sem) &amp;lt;- Lock B&lt;/p&gt;
&lt;p&gt;Lock Chain #1 (ip_alloc_sem -&amp;gt; orphan dir inode_lock):
ocfs2_dio_end_io_write
  down_write(&amp;amp;oi-&amp;gt;ip_alloc_sem) &amp;lt;- Lock B
  ocfs2_del_inode_from_orphan()
    inode_lock(orphan_dir_inode) &amp;lt;- Lock A&lt;/p&gt;
&lt;p&gt;Deadlock Scenario:
  CPU0 (unlink)                     CPU1 (dio_end_io_write)
  ------                            ------
  inode_lock(orphan_dir_inode)
                                    down_write(ip_alloc_sem)
  down_write(ip_alloc_sem)
                                    inode_lock(orphan_dir_inode)&lt;/p&gt;
&lt;p&gt;Since ip_alloc_sem is to protect allocation changes, which is unrelated
with operations in ocfs2_del_inode_from_orphan.  So move
ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-cqwh-r98h-2279</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-31598 — ocfs2: fix possible deadlock between unlink and dio_end_io_write</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-31598</link>
      <description>msrc_CVE-2026-31598</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-31598</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:10703-1 — kernel-devel-7.0.3-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:10703-1</link>
      <description>&lt;p&gt;kernel-devel-7.0.3-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-7.0.3-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:10703-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:23066-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:23066-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:23066-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-31598</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31598</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-azure, 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:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 237 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible deadlock between unlink and dio_end_io_write ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem, while in ocfs2_dio_end_io_write, it acquires these locks in reverse order. This creates an ABBA lock ordering violation on lock classes ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and ocfs2_file_ip_alloc_sem_key. Lock Chain #0 (orphan dir inode_lock -&amp;gt; ip_alloc_sem): ocfs2_unlink   ocfs2_prepare_orphan_dir     ocfs2_lookup_lock_orphan_dir       inode_lock(orphan_dir_inode) &amp;lt;- lock A     __ocfs2_prepare_orphan_dir       ocfs2_prepare_dir_for_insert         ocfs2_extend_dir 	  ocfs2_expand_inline_dir 	    down_write(&amp;amp;oi-&amp;gt;ip_alloc_sem) &amp;lt;- Lock B Lock Chain #1 (ip_alloc_sem -&amp;gt; orphan dir inode_lock): ocfs2_dio_end_io_write   down_write(&amp;amp;oi-&amp;gt;ip_alloc_sem) &amp;lt;- Lock B   ocfs2_del_inode_from_orphan()     inode_lock(orphan_dir_inode) &amp;lt;- Lock A Deadlock Scenario:   CPU0 (unlink)                     CPU1 (dio_end_io_write)   ------                            ------   inode_lock(orphan_dir_inode)                                     down_write(ip_alloc_sem)   down_write(ip_alloc_sem)                                     inode_lock(orphan_dir_inode) Since ip_alloc_sem is to protect allocation changes, which is unrelated with operations in ocfs2_del_inode_from_orphan.  So move ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-azure, 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:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 237 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible deadlock between unlink and dio_end_io_write ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem, while in ocfs2_dio_end_io_write, it acquires these locks in reverse order. This creates an ABBA lock ordering violation on lock classes ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and ocfs2_file_ip_alloc_sem_key. Lock Chain #0 (orphan dir inode_lock -&amp;gt; ip_alloc_sem): ocfs2_unlink   ocfs2_prepare_orphan_dir     ocfs2_lookup_lock_orphan_dir       inode_lock(orphan_dir_inode) &amp;lt;- lock A     __ocfs2_prepare_orphan_dir       ocfs2_prepare_dir_for_insert         ocfs2_extend_dir 	  ocfs2_expand_inline_dir 	    down_write(&amp;amp;oi-&amp;gt;ip_alloc_sem) &amp;lt;- Lock B Lock Chain #1 (ip_alloc_sem -&amp;gt; orphan dir inode_lock): ocfs2_dio_end_io_write   down_write(&amp;amp;oi-&amp;gt;ip_alloc_sem) &amp;lt;- Lock B   ocfs2_del_inode_from_orphan()     inode_lock(orphan_dir_inode) &amp;lt;- Lock A Deadlock Scenario:   CPU0 (unlink)                     CPU1 (dio_end_io_write)   ------                            ------   inode_lock(orphan_dir_inode)                                     down_write(ip_alloc_sem)   down_write(ip_alloc_sem)                                     inode_lock(orphan_dir_inode) Since ip_alloc_sem is to protect allocation changes, which is unrelated with operations in ocfs2_del_inode_from_orphan.  So move ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31598</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1279 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1279</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, welche zu einem Denial-of-Service-Zustand, einer Rechteausweitung, der Ausführung von Code oder einer Speicherbeschädigung führen könnten.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, welche zu einem Denial-of-Service-Zustand, einer Rechteausweitung, der Ausführung von Code oder einer Speicherbeschädigung führen könnten.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1279</guid>
    </item>
  </channel>
</rss>
