<?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 12:02:57 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-07904</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-07904</link>
      <description>bdu:2025-07904</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-07904</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-50229</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-50229</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-2024-50229</guid>
    </item>
    <item>
      <title>certfr-2024-avi-1031 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Elles permettent à un attaquant de provo…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-1031</link>
      <description>certfr-2024-avi-1031</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-1031</guid>
    </item>
    <item>
      <title>EUVD-2026-320722</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-320722</link>
      <description>EUVD-2026-320722</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-320722</guid>
    </item>
    <item>
      <title>fkie_cve-2024-50229</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-50229</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;nilfs2: fix potential deadlock with newly created symlinks&lt;/p&gt;
&lt;p&gt;Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers
memory reclamation involving the filesystem layer, which can result in
circular lock dependencies among the reader/writer semaphore
nilfs-&amp;gt;ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the
fs_reclaim pseudo lock.&lt;/p&gt;
&lt;p&gt;This is because after commit 21fc61c73c39 (&amp;#34;don&amp;#39;t put symlink bodies in
pagecache into highmem&amp;#34;), the gfp flags of the page cache for symbolic
links are overwritten to GFP_KERNEL via inode_nohighmem().&lt;/p&gt;
&lt;p&gt;This is not a problem for symlinks read from the backing device, because
the __GFP_FS flag is dropped after inode_nohighmem() is called.  However,
when a new symlink is created with nilfs_symlink(), the gfp flags remain
overwritten to GFP_KERNEL.  Then, memory allocation called from
page_symlink() etc.  triggers memory reclamation including the FS layer,
which may call nilfs_evict_inode() or nilfs_dirty_inode().  And these can
cause a deadlock if they are called while nilfs-&amp;gt;ns_segctor_sem is held:&lt;/p&gt;
&lt;p&gt;Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags
of newly created symlinks in the same way that nilfs_new_inode() and
__nilfs_read_inode() do, as a workaround until we adopt nofs allocation
scope consistently or improve the locking constraints.&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;nilfs2: fix potential deadlock with newly created symlinks&lt;/p&gt;
&lt;p&gt;Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers
memory reclamation involving the filesystem layer, which can result in
circular lock dependencies among the reader/writer semaphore
nilfs-&amp;gt;ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the
fs_reclaim pseudo lock.&lt;/p&gt;
&lt;p&gt;This is because after commit 21fc61c73c39 (&amp;#34;don&amp;#39;t put symlink bodies in
pagecache into highmem&amp;#34;), the gfp flags of the page cache for symbolic
links are overwritten to GFP_KERNEL via inode_nohighmem().&lt;/p&gt;
&lt;p&gt;This is not a problem for symlinks read from the backing device, because
the __GFP_FS flag is dropped after inode_nohighmem() is called.  However,
when a new symlink is created with nilfs_symlink(), the gfp flags remain
overwritten to GFP_KERNEL.  Then, memory allocation called from
page_symlink() etc.  triggers memory reclamation including the FS layer,
which may call nilfs_evict_inode() or nilfs_dirty_inode().  And these can
cause a deadlock if they are called while nilfs-&amp;gt;ns_segctor_sem is held:&lt;/p&gt;
&lt;p&gt;Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags
of newly created symlinks in the same way that nilfs_new_inode() and
__nilfs_read_inode() do, as a workaround until we adopt nofs allocation
scope consistently or improve the locking constraints.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-50229</guid>
    </item>
    <item>
      <title>GHSA-7h5p-3h8w-5629</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-7h5p-3h8w-5629</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;nilfs2: fix potential deadlock with newly created symlinks&lt;/p&gt;
&lt;p&gt;Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers
memory reclamation involving the filesystem layer, which can result in
circular lock dependencies among the reader/writer semaphore
nilfs-&amp;gt;ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the
fs_reclaim pseudo lock.&lt;/p&gt;
&lt;p&gt;This is because after commit 21fc61c73c39 (&amp;#34;don&amp;#39;t put symlink bodies in
pagecache into highmem&amp;#34;), the gfp flags of the page cache for symbolic
links are overwritten to GFP_KERNEL via inode_nohighmem().&lt;/p&gt;
&lt;p&gt;This is not a problem for symlinks read from the backing device, because
the __GFP_FS flag is dropped after inode_nohighmem() is called.  However,
when a new symlink is created with nilfs_symlink(), the gfp flags remain
overwritten to GFP_KERNEL.  Then, memory allocation called from
page_symlink() etc.  triggers memory reclamation including the FS layer,
which may call nilfs_evict_inode() or nilfs_dirty_inode().  And these can
cause a deadlock if they are called while nilfs-&amp;gt;ns_segctor_sem is held:&lt;/p&gt;
&lt;p&gt;Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags
of newly created symlinks in the same way that nilfs_new_inode() and
__nilfs_read_inode() do, as a workaround until we adopt nofs allocation
scope consistently or improve the locking constraints.&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;nilfs2: fix potential deadlock with newly created symlinks&lt;/p&gt;
&lt;p&gt;Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers
memory reclamation involving the filesystem layer, which can result in
circular lock dependencies among the reader/writer semaphore
nilfs-&amp;gt;ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the
fs_reclaim pseudo lock.&lt;/p&gt;
&lt;p&gt;This is because after commit 21fc61c73c39 (&amp;#34;don&amp;#39;t put symlink bodies in
pagecache into highmem&amp;#34;), the gfp flags of the page cache for symbolic
links are overwritten to GFP_KERNEL via inode_nohighmem().&lt;/p&gt;
&lt;p&gt;This is not a problem for symlinks read from the backing device, because
the __GFP_FS flag is dropped after inode_nohighmem() is called.  However,
when a new symlink is created with nilfs_symlink(), the gfp flags remain
overwritten to GFP_KERNEL.  Then, memory allocation called from
page_symlink() etc.  triggers memory reclamation including the FS layer,
which may call nilfs_evict_inode() or nilfs_dirty_inode().  And these can
cause a deadlock if they are called while nilfs-&amp;gt;ns_segctor_sem is held:&lt;/p&gt;
&lt;p&gt;Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags
of newly created symlinks in the same way that nilfs_new_inode() and
__nilfs_read_inode() do, as a workaround until we adopt nofs allocation
scope consistently or improve the locking constraints.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-7h5p-3h8w-5629</guid>
    </item>
    <item>
      <title>msrc_CVE-2024-50229 — nilfs2: fix potential deadlock with newly created symlinks</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2024-50229</link>
      <description>msrc_CVE-2024-50229</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2024-50229</guid>
    </item>
    <item>
      <title>OESA-2024-2491 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-2491</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP1: 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:  xen-netfront: Fix NULL sring after live migration  A NAPI is setup for each network sring to poll data to kernel The sring with source host is destroyed before live migration and new sring with target host is setup after live migration. The NAPI for the old sring is not deleted until setup new sring with target host after migration. With busy_poll/busy_read enabled, the NAPI can be polled before got deleted when resume VM.  BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: xennet_poll+0xae/0xd20 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI Call Trace:  finish_task_switch+0x71/0x230  timerqueue_del+0x1d/0x40  hrtimer_try_to_cancel+0xb5/0x110  xennet_alloc_rx_buffers+0x2a0/0x2a0  napi_busy_loop+0xdb/0x270  sock_poll+0x87/0x90  do_sys_poll+0x26f/0x580  tracing_map_insert+0x1d4/0x2f0  event_hist_trigger+0x14a/0x260   finish_task_switch+0x71/0x230  __schedule+0x256/0x890  recalc_sigpending+0x1b/0x50  xen_sched_clock+0x15/0x20  __rb_reserve_next+0x12d/0x140  ring_buffer_lock_reserve+0x123/0x3d0  event_triggers_call+0x87/0xb0  trace_event_buffer_commit+0x1c4/0x210  xen_clocksource_get_cycles+0x15/0x20  ktime_get_ts64+0x51/0xf0  SyS_ppoll+0x160/0x1a0  SyS_ppoll+0x160/0x1a0  do_syscall_64+0x73/0x130  entry_SYSCALL_64_after_hwframe+0x41/0xa6 ... RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900 CR2: 0000000000000008 ---[ en…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP1: 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:  xen-netfront: Fix NULL sring after live migration  A NAPI is setup for each network sring to poll data to kernel The sring with source host is destroyed before live migration and new sring with target host is setup after live migration. The NAPI for the old sring is not deleted until setup new sring with target host after migration. With busy_poll/busy_read enabled, the NAPI can be polled before got deleted when resume VM.  BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: xennet_poll+0xae/0xd20 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI Call Trace:  finish_task_switch+0x71/0x230  timerqueue_del+0x1d/0x40  hrtimer_try_to_cancel+0xb5/0x110  xennet_alloc_rx_buffers+0x2a0/0x2a0  napi_busy_loop+0xdb/0x270  sock_poll+0x87/0x90  do_sys_poll+0x26f/0x580  tracing_map_insert+0x1d4/0x2f0  event_hist_trigger+0x14a/0x260   finish_task_switch+0x71/0x230  __schedule+0x256/0x890  recalc_sigpending+0x1b/0x50  xen_sched_clock+0x15/0x20  __rb_reserve_next+0x12d/0x140  ring_buffer_lock_reserve+0x123/0x3d0  event_triggers_call+0x87/0xb0  trace_event_buffer_commit+0x1c4/0x210  xen_clocksource_get_cycles+0x15/0x20  ktime_get_ts64+0x51/0xf0  SyS_ppoll+0x160/0x1a0  SyS_ppoll+0x160/0x1a0  do_syscall_64+0x73/0x130  entry_SYSCALL_64_after_hwframe+0x41/0xa6 ... RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900 CR2: 0000000000000008 ---[ en…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-2491</guid>
    </item>
    <item>
      <title>openSUSE-SU-2024:14500-1 — kernel-devel-6.11.8-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2024:14500-1</link>
      <description>&lt;p&gt;kernel-devel-6.11.8-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-6.11.8-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2024:14500-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:4314-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:4314-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-2024:4314-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-50229</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-50229</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:Pro:16.04:LTS: linux-oracle, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 187 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs-&amp;gt;ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (&amp;#34;don&amp;#39;t put symlink bodies in pagecache into highmem&amp;#34;), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called.  However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL.  Then, memory allocation called from page_symlink() etc.  triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode().  And these can cause a deadlock if they are called while nilfs-&amp;gt;ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.&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:Pro:16.04:LTS: linux-oracle, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 187 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs-&amp;gt;ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (&amp;#34;don&amp;#39;t put symlink bodies in pagecache into highmem&amp;#34;), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called.  However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL.  Then, memory allocation called from page_symlink() etc.  triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode().  And these can cause a deadlock if they are called while nilfs-&amp;gt;ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-50229</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-3397 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3397</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher 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 nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3397</guid>
    </item>
  </channel>
</rss>
