<?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 05:02:39 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-03296</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-03296</link>
      <description>bdu:2025-03296</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-03296</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-47689</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-47689</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2024-47689</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0152 — De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un a…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0152</link>
      <description>certfr-2025-avi-0152</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0152</guid>
    </item>
    <item>
      <title>EUVD-2026-320694</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-320694</link>
      <description>EUVD-2026-320694</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-320694</guid>
    </item>
    <item>
      <title>fkie_cve-2024-47689</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-47689</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;f2fs: fix to don&amp;#39;t set SB_RDONLY in f2fs_handle_critical_error()&lt;/p&gt;
&lt;p&gt;syzbot reports a f2fs bug as below:&lt;/p&gt;
&lt;p&gt;------------[ cut here ]------------
WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177
CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0
Workqueue: events destroy_super_work
RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177
Call Trace:
 percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42
 destroy_super_work+0xec/0x130 fs/super.c:282
 process_one_work kernel/workqueue.c:3231 [inline]
 process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312
 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390
 kthread+0x2f0/0x390 kernel/kthread.c:389
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244&lt;/p&gt;
&lt;p&gt;As Christian Brauner pointed out [1]: the root cause is f2fs sets
SB_RDONLY flag in internal function, rather than setting the flag
covered w/ sb-&amp;gt;s_umount semaphore via remount procedure, then below
race condition causes this bug:&lt;/p&gt;
&lt;p&gt;- freeze_super()
 - sb_wait_write(sb, SB_FREEZE_WRITE)
 - sb_wait_write(sb, SB_FREEZE_PAGEFAULT)
 - sb_wait_write(sb, SB_FREEZE_FS)
					- f2fs_handle_critical_error
					 - sb-&amp;gt;s_flags |= SB_RDONLY
- thaw_super
 - thaw_super_locked
  - sb_rdonly() is true, so it skips
    sb_freeze_unlock(sb, SB_FREEZE_FS)
  - deactivate_locked_sup…&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 don&amp;#39;t set SB_RDONLY in f2fs_handle_critical_error()&lt;/p&gt;
&lt;p&gt;syzbot reports a f2fs bug as below:&lt;/p&gt;
&lt;p&gt;------------[ cut here ]------------
WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177
CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0
Workqueue: events destroy_super_work
RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177
Call Trace:
 percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42
 destroy_super_work+0xec/0x130 fs/super.c:282
 process_one_work kernel/workqueue.c:3231 [inline]
 process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312
 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390
 kthread+0x2f0/0x390 kernel/kthread.c:389
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244&lt;/p&gt;
&lt;p&gt;As Christian Brauner pointed out [1]: the root cause is f2fs sets
SB_RDONLY flag in internal function, rather than setting the flag
covered w/ sb-&amp;gt;s_umount semaphore via remount procedure, then below
race condition causes this bug:&lt;/p&gt;
&lt;p&gt;- freeze_super()
 - sb_wait_write(sb, SB_FREEZE_WRITE)
 - sb_wait_write(sb, SB_FREEZE_PAGEFAULT)
 - sb_wait_write(sb, SB_FREEZE_FS)
					- f2fs_handle_critical_error
					 - sb-&amp;gt;s_flags |= SB_RDONLY
- thaw_super
 - thaw_super_locked
  - sb_rdonly() is true, so it skips
    sb_freeze_unlock(sb, SB_FREEZE_FS)
  - deactivate_locked_sup…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-47689</guid>
    </item>
    <item>
      <title>GHSA-qvwj-r2mj-jh93</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-qvwj-r2mj-jh93</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;f2fs: fix to don&amp;#39;t set SB_RDONLY in f2fs_handle_critical_error()&lt;/p&gt;
&lt;p&gt;syzbot reports a f2fs bug as below:&lt;/p&gt;
&lt;p&gt;------------[ cut here ]------------
WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177
CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0
Workqueue: events destroy_super_work
RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177
Call Trace:
 percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42
 destroy_super_work+0xec/0x130 fs/super.c:282
 process_one_work kernel/workqueue.c:3231 [inline]
 process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312
 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390
 kthread+0x2f0/0x390 kernel/kthread.c:389
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244&lt;/p&gt;
&lt;p&gt;As Christian Brauner pointed out [1]: the root cause is f2fs sets
SB_RDONLY flag in internal function, rather than setting the flag
covered w/ sb-&amp;gt;s_umount semaphore via remount procedure, then below
race condition causes this bug:&lt;/p&gt;
&lt;p&gt;- freeze_super()
 - sb_wait_write(sb, SB_FREEZE_WRITE)
 - sb_wait_write(sb, SB_FREEZE_PAGEFAULT)
 - sb_wait_write(sb, SB_FREEZE_FS)
					- f2fs_handle_critical_error
					 - sb-&amp;gt;s_flags |= SB_RDONLY
- thaw_super
 - thaw_super_locked
  - sb_rdonly() is true, so it skips
    sb_freeze_unlock(sb, SB_FREEZE_FS)
  - deactivate_locked_sup…&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 don&amp;#39;t set SB_RDONLY in f2fs_handle_critical_error()&lt;/p&gt;
&lt;p&gt;syzbot reports a f2fs bug as below:&lt;/p&gt;
&lt;p&gt;------------[ cut here ]------------
WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177
CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0
Workqueue: events destroy_super_work
RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177
Call Trace:
 percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42
 destroy_super_work+0xec/0x130 fs/super.c:282
 process_one_work kernel/workqueue.c:3231 [inline]
 process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312
 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390
 kthread+0x2f0/0x390 kernel/kthread.c:389
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244&lt;/p&gt;
&lt;p&gt;As Christian Brauner pointed out [1]: the root cause is f2fs sets
SB_RDONLY flag in internal function, rather than setting the flag
covered w/ sb-&amp;gt;s_umount semaphore via remount procedure, then below
race condition causes this bug:&lt;/p&gt;
&lt;p&gt;- freeze_super()
 - sb_wait_write(sb, SB_FREEZE_WRITE)
 - sb_wait_write(sb, SB_FREEZE_PAGEFAULT)
 - sb_wait_write(sb, SB_FREEZE_FS)
					- f2fs_handle_critical_error
					 - sb-&amp;gt;s_flags |= SB_RDONLY
- thaw_super
 - thaw_super_locked
  - sb_rdonly() is true, so it skips
    sb_freeze_unlock(sb, SB_FREEZE_FS)
  - deactivate_locked_sup…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-qvwj-r2mj-jh93</guid>
    </item>
    <item>
      <title>msrc_CVE-2024-47689 — f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error()</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2024-47689</link>
      <description>msrc_CVE-2024-47689</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2024-47689</guid>
    </item>
    <item>
      <title>OESA-2024-2325 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-2325</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS: 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:  ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir()  The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.(CVE-2023-52917)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:  media: pci: cx23885: check cx23885_vdev_init() return  cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check.  Add a NULL pointer check and go to the error unwind if it is NULL.(CVE-2023-52918)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
btrfs: make sure that WRITTEN is set on all metadata blocks&#13;
&#13;
We previously would call btrfs_check_leaf() if we had the check
integrity code enabled, which meant that we could only run the extended
leaf checks if we had WRITTEN set on the header flags.&#13;
&#13;
This leaves a gap in our checking, because we could end up with
corruption on disk where WRITTEN isn&amp;amp;apos;t set on the leaf, and then the
extended leaf checks don&amp;amp;apos;t get run which we rely on to validate all of
the item pointers to make sure we don&amp;amp;apos;t access memory outside of the
extent buffer.&#13;
&#13;
However, since 732fab95abe2 (&amp;amp;quot;btrfs: check-integrity: remove
CONFIG_BTRFS_FS_CHECK_INTEGRITY option&amp;amp;quot;) we no longer call
btrfs_check_leaf() from btrfs_mark_buffer_dirty(), which means we only
ever c…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS: 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:  ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir()  The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.(CVE-2023-52917)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:  media: pci: cx23885: check cx23885_vdev_init() return  cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check.  Add a NULL pointer check and go to the error unwind if it is NULL.(CVE-2023-52918)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
btrfs: make sure that WRITTEN is set on all metadata blocks&#13;
&#13;
We previously would call btrfs_check_leaf() if we had the check
integrity code enabled, which meant that we could only run the extended
leaf checks if we had WRITTEN set on the header flags.&#13;
&#13;
This leaves a gap in our checking, because we could end up with
corruption on disk where WRITTEN isn&amp;amp;apos;t set on the leaf, and then the
extended leaf checks don&amp;amp;apos;t get run which we rely on to validate all of
the item pointers to make sure we don&amp;amp;apos;t access memory outside of the
extent buffer.&#13;
&#13;
However, since 732fab95abe2 (&amp;amp;quot;btrfs: check-integrity: remove
CONFIG_BTRFS_FS_CHECK_INTEGRITY option&amp;amp;quot;) we no longer call
btrfs_check_leaf() from btrfs_mark_buffer_dirty(), which means we only
ever c…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-2325</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>UBUNTU-CVE-2024-47689</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-47689</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 194 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don&amp;#39;t set SB_RDONLY in f2fs_handle_critical_error() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroy_super_work RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace:  percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42  destroy_super_work+0xec/0x130 fs/super.c:282  process_one_work kernel/workqueue.c:3231 [inline]  process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312  worker_thread+0x86d/0xd40 kernel/workqueue.c:3390  kthread+0x2f0/0x390 kernel/kthread.c:389  ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 As Christian Brauner pointed out [1]: the root cause is f2fs sets SB_RDONLY flag in internal function, rather than setting the flag covered w/ sb-&amp;gt;s_umount semaphore via remount procedure, then below race condition causes this bug: - freeze_super()  - sb_wait_write(sb, SB_FREEZE_WRITE)  - sb_wait_write(sb, SB_FREEZE_PAGEFAULT)  - sb_wait_write(sb, SB_FREEZE_FS) 					- f2fs_handle_critical_error 					 - sb-&amp;gt;s_flags |= SB_RDONLY - thaw_super  - thaw_super_locked   - sb_rdonly() is true, so it skips     sb_freeze_unlock(sb, SB_FREEZE_FS)   - deactivate_locked_super Si…&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 194 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don&amp;#39;t set SB_RDONLY in f2fs_handle_critical_error() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroy_super_work RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace:  percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42  destroy_super_work+0xec/0x130 fs/super.c:282  process_one_work kernel/workqueue.c:3231 [inline]  process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312  worker_thread+0x86d/0xd40 kernel/workqueue.c:3390  kthread+0x2f0/0x390 kernel/kthread.c:389  ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 As Christian Brauner pointed out [1]: the root cause is f2fs sets SB_RDONLY flag in internal function, rather than setting the flag covered w/ sb-&amp;gt;s_umount semaphore via remount procedure, then below race condition causes this bug: - freeze_super()  - sb_wait_write(sb, SB_FREEZE_WRITE)  - sb_wait_write(sb, SB_FREEZE_PAGEFAULT)  - sb_wait_write(sb, SB_FREEZE_FS) 					- f2fs_handle_critical_error 					 - sb-&amp;gt;s_flags |= SB_RDONLY - thaw_super  - thaw_super_locked   - sb_rdonly() is true, so it skips     sb_freeze_unlock(sb, SB_FREEZE_FS)   - deactivate_locked_super Si…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-47689</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-3251 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3251</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere, nicht näher bekannte Auswirkungen zu erzielen..&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere, nicht näher bekannte Auswirkungen zu erzielen..&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3251</guid>
    </item>
  </channel>
</rss>
