<?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 03:13:52 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-05736</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-05736</link>
      <description>bdu:2026-05736</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-05736</guid>
    </item>
    <item>
      <title>BELL-CVE-2023-53149</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2023-53149</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: 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:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2023-53149</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0895 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0895</link>
      <description>certfr-2025-avi-0895</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0895</guid>
    </item>
    <item>
      <title>EUVD-2026-311868</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-311868</link>
      <description>EUVD-2026-311868</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-311868</guid>
    </item>
    <item>
      <title>fkie_cve-2023-53149</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-53149</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ext4: avoid deadlock in fs reclaim with page writeback&lt;/p&gt;
&lt;p&gt;Ext4 has a filesystem wide lock protecting ext4_writepages() calls to
avoid races with switching of journalled data flag or inode format. This
lock can however cause a deadlock like:&lt;/p&gt;
&lt;p&gt;CPU0                            CPU1&lt;/p&gt;
&lt;p&gt;ext4_writepages()
  percpu_down_read(sbi-&amp;gt;s_writepages_rwsem);
                                ext4_change_inode_journal_flag()
                                  percpu_down_write(sbi-&amp;gt;s_writepages_rwsem);
                                    - blocks, all readers block from now on
  ext4_do_writepages()
    ext4_init_io_end()
      kmem_cache_zalloc(io_end_cachep, GFP_KERNEL)
        fs_reclaim frees dentry...
          dentry_unlink_inode()
            iput() - last ref =&amp;gt;
              iput_final() - inode dirty =&amp;gt;
                write_inode_now()...
                  ext4_writepages() tries to acquire sbi-&amp;gt;s_writepages_rwsem
                    and blocks forever&lt;/p&gt;
&lt;p&gt;Make sure we cannot recurse into filesystem reclaim from writeback code
to avoid 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;ext4: avoid deadlock in fs reclaim with page writeback&lt;/p&gt;
&lt;p&gt;Ext4 has a filesystem wide lock protecting ext4_writepages() calls to
avoid races with switching of journalled data flag or inode format. This
lock can however cause a deadlock like:&lt;/p&gt;
&lt;p&gt;CPU0                            CPU1&lt;/p&gt;
&lt;p&gt;ext4_writepages()
  percpu_down_read(sbi-&amp;gt;s_writepages_rwsem);
                                ext4_change_inode_journal_flag()
                                  percpu_down_write(sbi-&amp;gt;s_writepages_rwsem);
                                    - blocks, all readers block from now on
  ext4_do_writepages()
    ext4_init_io_end()
      kmem_cache_zalloc(io_end_cachep, GFP_KERNEL)
        fs_reclaim frees dentry...
          dentry_unlink_inode()
            iput() - last ref =&amp;gt;
              iput_final() - inode dirty =&amp;gt;
                write_inode_now()...
                  ext4_writepages() tries to acquire sbi-&amp;gt;s_writepages_rwsem
                    and blocks forever&lt;/p&gt;
&lt;p&gt;Make sure we cannot recurse into filesystem reclaim from writeback code
to avoid the deadlock.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-53149</guid>
    </item>
    <item>
      <title>GHSA-3gfc-6fjv-pj6m</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-3gfc-6fjv-pj6m</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ext4: avoid deadlock in fs reclaim with page writeback&lt;/p&gt;
&lt;p&gt;Ext4 has a filesystem wide lock protecting ext4_writepages() calls to
avoid races with switching of journalled data flag or inode format. This
lock can however cause a deadlock like:&lt;/p&gt;
&lt;p&gt;CPU0                            CPU1&lt;/p&gt;
&lt;p&gt;ext4_writepages()
  percpu_down_read(sbi-&amp;gt;s_writepages_rwsem);
                                ext4_change_inode_journal_flag()
                                  percpu_down_write(sbi-&amp;gt;s_writepages_rwsem);
                                    - blocks, all readers block from now on
  ext4_do_writepages()
    ext4_init_io_end()
      kmem_cache_zalloc(io_end_cachep, GFP_KERNEL)
        fs_reclaim frees dentry...
          dentry_unlink_inode()
            iput() - last ref =&amp;gt;
              iput_final() - inode dirty =&amp;gt;
                write_inode_now()...
                  ext4_writepages() tries to acquire sbi-&amp;gt;s_writepages_rwsem
                    and blocks forever&lt;/p&gt;
&lt;p&gt;Make sure we cannot recurse into filesystem reclaim from writeback code
to avoid 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;ext4: avoid deadlock in fs reclaim with page writeback&lt;/p&gt;
&lt;p&gt;Ext4 has a filesystem wide lock protecting ext4_writepages() calls to
avoid races with switching of journalled data flag or inode format. This
lock can however cause a deadlock like:&lt;/p&gt;
&lt;p&gt;CPU0                            CPU1&lt;/p&gt;
&lt;p&gt;ext4_writepages()
  percpu_down_read(sbi-&amp;gt;s_writepages_rwsem);
                                ext4_change_inode_journal_flag()
                                  percpu_down_write(sbi-&amp;gt;s_writepages_rwsem);
                                    - blocks, all readers block from now on
  ext4_do_writepages()
    ext4_init_io_end()
      kmem_cache_zalloc(io_end_cachep, GFP_KERNEL)
        fs_reclaim frees dentry...
          dentry_unlink_inode()
            iput() - last ref =&amp;gt;
              iput_final() - inode dirty =&amp;gt;
                write_inode_now()...
                  ext4_writepages() tries to acquire sbi-&amp;gt;s_writepages_rwsem
                    and blocks forever&lt;/p&gt;
&lt;p&gt;Make sure we cannot recurse into filesystem reclaim from writeback code
to avoid the deadlock.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-3gfc-6fjv-pj6m</guid>
    </item>
    <item>
      <title>msrc_CVE-2023-53149 — ext4: avoid deadlock in fs reclaim with page writeback</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2023-53149</link>
      <description>msrc_CVE-2023-53149</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2023-53149</guid>
    </item>
    <item>
      <title>OESA-2025-2348 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-2348</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.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&amp;amp;apos;s JSM serial driver, a resource leak vulnerability exists in the probe function. The error path needs to properly unwind instead of just returning directly, which may lead to resource leakage issues.(CVE-2022-50312)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;rapidio: fix possible name leaks when rio_add_device() fails&lt;/p&gt;
&lt;p&gt;Patch series &amp;amp;quot;rapidio: fix three possible memory leaks&amp;amp;quot;.&lt;/p&gt;
&lt;p&gt;This patchset fixes three name leaks in error handling.
 - patch #1 fixes two name leaks while rio_add_device() fails.
 - patch #2 fixes a name leak while  rio_register_mport() fails.&lt;/p&gt;
&lt;p&gt;This patch (of 2):&lt;/p&gt;
&lt;p&gt;If rio_add_device() returns error, the name allocated by dev_set_name()
need be freed.  It should use put_device() to give up the reference in the
error path, so that the name can be freed in kobject_cleanup(), and the
&amp;amp;apos;rdev&amp;amp;apos; can be freed in rio_release_dev().(CVE-2022-50343)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, there is a memory leak vulnerability in the tpm_crb driver. In the crb_acpi_add() function, after obtaining the TPM2 table to retrieve information such as startup methods and assigning them to private data, the TPM2 table is no longer used after initialization is completed, but is not released correctly, resulting in memory leaks.(CVE-2022-50389)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ext4: avoid deadlock in fs reclaim with page write…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.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&amp;amp;apos;s JSM serial driver, a resource leak vulnerability exists in the probe function. The error path needs to properly unwind instead of just returning directly, which may lead to resource leakage issues.(CVE-2022-50312)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;rapidio: fix possible name leaks when rio_add_device() fails&lt;/p&gt;
&lt;p&gt;Patch series &amp;amp;quot;rapidio: fix three possible memory leaks&amp;amp;quot;.&lt;/p&gt;
&lt;p&gt;This patchset fixes three name leaks in error handling.
 - patch #1 fixes two name leaks while rio_add_device() fails.
 - patch #2 fixes a name leak while  rio_register_mport() fails.&lt;/p&gt;
&lt;p&gt;This patch (of 2):&lt;/p&gt;
&lt;p&gt;If rio_add_device() returns error, the name allocated by dev_set_name()
need be freed.  It should use put_device() to give up the reference in the
error path, so that the name can be freed in kobject_cleanup(), and the
&amp;amp;apos;rdev&amp;amp;apos; can be freed in rio_release_dev().(CVE-2022-50343)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, there is a memory leak vulnerability in the tpm_crb driver. In the crb_acpi_add() function, after obtaining the TPM2 table to retrieve information such as startup methods and assigning them to private data, the TPM2 table is no longer used after initialization is completed, but is not released correctly, resulting in memory leaks.(CVE-2022-50389)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ext4: avoid deadlock in fs reclaim with page write…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-2348</guid>
    </item>
    <item>
      <title>RHSA-2024:2394 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2024:2394</link>
      <description>&lt;p&gt;kernel: Bluetooth BR/EDR PIN Pairing procedure is vulnerable to an impersonation attack kernel: ovl: fix warning in ovl_create_real() kernel: memcg does not limit the number of POSIX file locks allowing memory exhaustion kernel: vmwgfx: NULL pointer dereference in vmw_cmd_dx_define_query kernel: integer overflow in l2cap_config_req() in net/bluetooth/l2cap_core.c kernel: i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() kernel: Bluetooth: L2CAP: Fix u8 overflow kernel: hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new() kernel: tracing: Fix sleeping function called from invalid context on RT kernel kernel: net: mdio: unexport __init-annotated mdio_bus_init() kernel: arm64: ftrace: consistently handle PLTs. kernel: mm/uffd: fix pte marker when fork() without fork event kernel: Bluetooth: Fix a buffer overflow in mgmt_mesh_add() kernel: tty: n_gsm: add sanity check for gsm-&amp;gt;receive in gsm_receive_buf() kernel: ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead kernel: tee: add overflow check in register_shm_helper() kernel: tty: n_gsm: fix deadlock and link starvation in outgoing data path kernel: PM: hibernate: defer device probing when resuming from hibernation kernel: ext4: don&amp;#39;t allow journal inode to have encrypt flag kernel: ext4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline kernel: erofs: fix order &amp;gt;= MAX_ORDER warning due to crafted negative i_size kernel: perf/x86/intel/uncore: F…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: Bluetooth BR/EDR PIN Pairing procedure is vulnerable to an impersonation attack kernel: ovl: fix warning in ovl_create_real() kernel: memcg does not limit the number of POSIX file locks allowing memory exhaustion kernel: vmwgfx: NULL pointer dereference in vmw_cmd_dx_define_query kernel: integer overflow in l2cap_config_req() in net/bluetooth/l2cap_core.c kernel: i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() kernel: Bluetooth: L2CAP: Fix u8 overflow kernel: hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new() kernel: tracing: Fix sleeping function called from invalid context on RT kernel kernel: net: mdio: unexport __init-annotated mdio_bus_init() kernel: arm64: ftrace: consistently handle PLTs. kernel: mm/uffd: fix pte marker when fork() without fork event kernel: Bluetooth: Fix a buffer overflow in mgmt_mesh_add() kernel: tty: n_gsm: add sanity check for gsm-&amp;gt;receive in gsm_receive_buf() kernel: ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead kernel: tee: add overflow check in register_shm_helper() kernel: tty: n_gsm: fix deadlock and link starvation in outgoing data path kernel: PM: hibernate: defer device probing when resuming from hibernation kernel: ext4: don&amp;#39;t allow journal inode to have encrypt flag kernel: ext4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline kernel: erofs: fix order &amp;gt;= MAX_ORDER warning due to crafted negative i_size kernel: perf/x86/intel/uncore: F…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2024:2394</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:03614-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:03614-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-2025:03614-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-53149</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53149</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 163 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ext4: avoid deadlock in fs reclaim with page writeback Ext4 has a filesystem wide lock protecting ext4_writepages() calls to avoid races with switching of journalled data flag or inode format. This lock can however cause a deadlock like: CPU0                            CPU1 ext4_writepages()   percpu_down_read(sbi-&amp;gt;s_writepages_rwsem);                                 ext4_change_inode_journal_flag() percpu_down_write(sbi-&amp;gt;s_writepages_rwsem);                                     - blocks, all readers block from now on   ext4_do_writepages()     ext4_init_io_end()       kmem_cache_zalloc(io_end_cachep, GFP_KERNEL)         fs_reclaim frees dentry...           dentry_unlink_inode()             iput() - last ref =&amp;gt;               iput_final() - inode dirty =&amp;gt;                 write_inode_now()...                   ext4_writepages() tries to acquire sbi-&amp;gt;s_writepages_rwsem                     and blocks forever Make sure we cannot recurse into filesystem reclaim from writeback code to avoid 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 163 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ext4: avoid deadlock in fs reclaim with page writeback Ext4 has a filesystem wide lock protecting ext4_writepages() calls to avoid races with switching of journalled data flag or inode format. This lock can however cause a deadlock like: CPU0                            CPU1 ext4_writepages()   percpu_down_read(sbi-&amp;gt;s_writepages_rwsem);                                 ext4_change_inode_journal_flag() percpu_down_write(sbi-&amp;gt;s_writepages_rwsem);                                     - blocks, all readers block from now on   ext4_do_writepages()     ext4_init_io_end()       kmem_cache_zalloc(io_end_cachep, GFP_KERNEL)         fs_reclaim frees dentry...           dentry_unlink_inode()             iput() - last ref =&amp;gt;               iput_final() - inode dirty =&amp;gt;                 write_inode_now()...                   ext4_writepages() tries to acquire sbi-&amp;gt;s_writepages_rwsem                     and blocks forever Make sure we cannot recurse into filesystem reclaim from writeback code to avoid the deadlock.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53149</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2053 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2053</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht näher beschriebene Auswirkungen zu erzielen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht näher beschriebene Auswirkungen zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2053</guid>
    </item>
  </channel>
</rss>
