<?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 11:40:41 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-06009</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-06009</link>
      <description>bdu:2026-06009</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-06009</guid>
    </item>
    <item>
      <title>BELL-CVE-2023-53331</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2023-53331</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-53331</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-345182</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-345182</link>
      <description>EUVD-2026-345182</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-345182</guid>
    </item>
    <item>
      <title>fkie_cve-2023-53331</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-53331</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;pstore/ram: Check start of empty przs during init&lt;/p&gt;
&lt;p&gt;After commit 30696378f68a (&amp;#34;pstore/ram: Do not treat empty buffers as
valid&amp;#34;), initialization would assume a prz was valid after seeing that
the buffer_size is zero (regardless of the buffer start position). This
unchecked start value means it could be outside the bounds of the buffer,
leading to future access panics when written to:&lt;/p&gt;
&lt;p&gt;sysdump_panic_event+0x3b4/0x5b8
 atomic_notifier_call_chain+0x54/0x90
 panic+0x1c8/0x42c
 die+0x29c/0x2a8
 die_kernel_fault+0x68/0x78
 __do_kernel_fault+0x1c4/0x1e0
 do_bad_area+0x40/0x100
 do_translation_fault+0x68/0x80
 do_mem_abort+0x68/0xf8
 el1_da+0x1c/0xc0
 __raw_writeb+0x38/0x174
 __memcpy_toio+0x40/0xac
 persistent_ram_update+0x44/0x12c
 persistent_ram_write+0x1a8/0x1b8
 ramoops_pstore_write+0x198/0x1e8
 pstore_console_write+0x94/0xe0
 ...&lt;/p&gt;
&lt;p&gt;To avoid this, also check if the prz start is 0 during the initialization
phase. If not, the next prz sanity check case will discover it (start &amp;gt;
size) and zap the buffer back to a sane state.&lt;/p&gt;
&lt;p&gt;[kees: update commit log with backtrace and clarifications]&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;pstore/ram: Check start of empty przs during init&lt;/p&gt;
&lt;p&gt;After commit 30696378f68a (&amp;#34;pstore/ram: Do not treat empty buffers as
valid&amp;#34;), initialization would assume a prz was valid after seeing that
the buffer_size is zero (regardless of the buffer start position). This
unchecked start value means it could be outside the bounds of the buffer,
leading to future access panics when written to:&lt;/p&gt;
&lt;p&gt;sysdump_panic_event+0x3b4/0x5b8
 atomic_notifier_call_chain+0x54/0x90
 panic+0x1c8/0x42c
 die+0x29c/0x2a8
 die_kernel_fault+0x68/0x78
 __do_kernel_fault+0x1c4/0x1e0
 do_bad_area+0x40/0x100
 do_translation_fault+0x68/0x80
 do_mem_abort+0x68/0xf8
 el1_da+0x1c/0xc0
 __raw_writeb+0x38/0x174
 __memcpy_toio+0x40/0xac
 persistent_ram_update+0x44/0x12c
 persistent_ram_write+0x1a8/0x1b8
 ramoops_pstore_write+0x198/0x1e8
 pstore_console_write+0x94/0xe0
 ...&lt;/p&gt;
&lt;p&gt;To avoid this, also check if the prz start is 0 during the initialization
phase. If not, the next prz sanity check case will discover it (start &amp;gt;
size) and zap the buffer back to a sane state.&lt;/p&gt;
&lt;p&gt;[kees: update commit log with backtrace and clarifications]&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-53331</guid>
    </item>
    <item>
      <title>GHSA-v4w9-9vv8-m7qj</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-v4w9-9vv8-m7qj</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;pstore/ram: Check start of empty przs during init&lt;/p&gt;
&lt;p&gt;After commit 30696378f68a (&amp;#34;pstore/ram: Do not treat empty buffers as
valid&amp;#34;), initialization would assume a prz was valid after seeing that
the buffer_size is zero (regardless of the buffer start position). This
unchecked start value means it could be outside the bounds of the buffer,
leading to future access panics when written to:&lt;/p&gt;
&lt;p&gt;sysdump_panic_event+0x3b4/0x5b8
 atomic_notifier_call_chain+0x54/0x90
 panic+0x1c8/0x42c
 die+0x29c/0x2a8
 die_kernel_fault+0x68/0x78
 __do_kernel_fault+0x1c4/0x1e0
 do_bad_area+0x40/0x100
 do_translation_fault+0x68/0x80
 do_mem_abort+0x68/0xf8
 el1_da+0x1c/0xc0
 __raw_writeb+0x38/0x174
 __memcpy_toio+0x40/0xac
 persistent_ram_update+0x44/0x12c
 persistent_ram_write+0x1a8/0x1b8
 ramoops_pstore_write+0x198/0x1e8
 pstore_console_write+0x94/0xe0
 ...&lt;/p&gt;
&lt;p&gt;To avoid this, also check if the prz start is 0 during the initialization
phase. If not, the next prz sanity check case will discover it (start &amp;gt;
size) and zap the buffer back to a sane state.&lt;/p&gt;
&lt;p&gt;[kees: update commit log with backtrace and clarifications]&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;pstore/ram: Check start of empty przs during init&lt;/p&gt;
&lt;p&gt;After commit 30696378f68a (&amp;#34;pstore/ram: Do not treat empty buffers as
valid&amp;#34;), initialization would assume a prz was valid after seeing that
the buffer_size is zero (regardless of the buffer start position). This
unchecked start value means it could be outside the bounds of the buffer,
leading to future access panics when written to:&lt;/p&gt;
&lt;p&gt;sysdump_panic_event+0x3b4/0x5b8
 atomic_notifier_call_chain+0x54/0x90
 panic+0x1c8/0x42c
 die+0x29c/0x2a8
 die_kernel_fault+0x68/0x78
 __do_kernel_fault+0x1c4/0x1e0
 do_bad_area+0x40/0x100
 do_translation_fault+0x68/0x80
 do_mem_abort+0x68/0xf8
 el1_da+0x1c/0xc0
 __raw_writeb+0x38/0x174
 __memcpy_toio+0x40/0xac
 persistent_ram_update+0x44/0x12c
 persistent_ram_write+0x1a8/0x1b8
 ramoops_pstore_write+0x198/0x1e8
 pstore_console_write+0x94/0xe0
 ...&lt;/p&gt;
&lt;p&gt;To avoid this, also check if the prz start is 0 during the initialization
phase. If not, the next prz sanity check case will discover it (start &amp;gt;
size) and zap the buffer back to a sane state.&lt;/p&gt;
&lt;p&gt;[kees: update commit log with backtrace and clarifications]&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-v4w9-9vv8-m7qj</guid>
    </item>
    <item>
      <title>OESA-2025-2407 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-2407</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: 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;net: dsa: Avoid cross-chip syncing of VLAN filtering&lt;/p&gt;
&lt;p&gt;Changes to VLAN filtering are not applicable to cross-chip
notifications.&lt;/p&gt;
&lt;p&gt;On a system like this:&lt;/p&gt;
&lt;p&gt;.-----.   .-----.   .-----.
| sw1 +---+ sw2 +---+ sw3 |
&amp;amp;apos;-1-2-&amp;amp;apos;   &amp;amp;apos;-1-2-&amp;amp;apos;   &amp;amp;apos;-1-2-&amp;amp;apos;&lt;/p&gt;
&lt;p&gt;Before this change, upon sw1p1 leaving a bridge, a call to
dsa_port_vlan_filtering would also be made to sw2p1 and sw3p1.&lt;/p&gt;
&lt;p&gt;In this scenario:&lt;/p&gt;
&lt;p&gt;.---------.   .-----.   .-----.
|   sw1   +---+ sw2 +---+ sw3 |
&amp;amp;apos;-1-2-3-4-&amp;amp;apos;   &amp;amp;apos;-1-2-&amp;amp;apos;   &amp;amp;apos;-1-2-&amp;amp;apos;&lt;/p&gt;
&lt;p&gt;When sw1p4 would leave a bridge, dsa_port_vlan_filtering would be
called for sw2 and sw3 with a non-existing port - leading to array
out-of-bounds accesses and crashes on mv88e6xxx.(CVE-2022-49234)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;scsi: target: iscsi: Fix a race condition between login_work and the login thread&lt;/p&gt;
&lt;p&gt;In case a malicious initiator sends some random data immediately after a
login PDU; the iscsi_target_sk_data_ready() callback will schedule the
login_work and, at the same time, the negotiation may end without clearing
the LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges are
required to complete the login).&lt;/p&gt;
&lt;p&gt;The login has been completed but the login_work function will find the
LOGIN_FLAGS_INITIAL_PDU flag set and will never stop from rescheduling…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: 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;net: dsa: Avoid cross-chip syncing of VLAN filtering&lt;/p&gt;
&lt;p&gt;Changes to VLAN filtering are not applicable to cross-chip
notifications.&lt;/p&gt;
&lt;p&gt;On a system like this:&lt;/p&gt;
&lt;p&gt;.-----.   .-----.   .-----.
| sw1 +---+ sw2 +---+ sw3 |
&amp;amp;apos;-1-2-&amp;amp;apos;   &amp;amp;apos;-1-2-&amp;amp;apos;   &amp;amp;apos;-1-2-&amp;amp;apos;&lt;/p&gt;
&lt;p&gt;Before this change, upon sw1p1 leaving a bridge, a call to
dsa_port_vlan_filtering would also be made to sw2p1 and sw3p1.&lt;/p&gt;
&lt;p&gt;In this scenario:&lt;/p&gt;
&lt;p&gt;.---------.   .-----.   .-----.
|   sw1   +---+ sw2 +---+ sw3 |
&amp;amp;apos;-1-2-3-4-&amp;amp;apos;   &amp;amp;apos;-1-2-&amp;amp;apos;   &amp;amp;apos;-1-2-&amp;amp;apos;&lt;/p&gt;
&lt;p&gt;When sw1p4 would leave a bridge, dsa_port_vlan_filtering would be
called for sw2 and sw3 with a non-existing port - leading to array
out-of-bounds accesses and crashes on mv88e6xxx.(CVE-2022-49234)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;scsi: target: iscsi: Fix a race condition between login_work and the login thread&lt;/p&gt;
&lt;p&gt;In case a malicious initiator sends some random data immediately after a
login PDU; the iscsi_target_sk_data_ready() callback will schedule the
login_work and, at the same time, the negotiation may end without clearing
the LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges are
required to complete the login).&lt;/p&gt;
&lt;p&gt;The login has been completed but the login_work function will find the
LOGIN_FLAGS_INITIAL_PDU flag set and will never stop from rescheduling…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-2407</guid>
    </item>
    <item>
      <title>RHSA-2025:19105 — Red Hat Security Advisory: kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2025:19105</link>
      <description>&lt;p&gt;kernel: pstore/ram: Check start of empty przs during init kernel: block: fix adding folio to bio kernel: vsock/virtio: Validate length in packet header before skb_put() kernel: NFS: Fix filehandle bounds checking in nfs_fh_to_dentry() kernel: Linux kernel ALSA hda/ca0132 buffer overflow kernel: Linux kernel: Denial of Service via resource leak in SMB2 compound operations&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: pstore/ram: Check start of empty przs during init kernel: block: fix adding folio to bio kernel: vsock/virtio: Validate length in packet header before skb_put() kernel: NFS: Fix filehandle bounds checking in nfs_fh_to_dentry() kernel: Linux kernel ALSA hda/ca0132 buffer overflow kernel: Linux kernel: Denial of Service via resource leak in SMB2 compound operations&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2025:19105</guid>
    </item>
    <item>
      <title>RHSA-2025:19886 — Red Hat Security Advisory: kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2025:19886</link>
      <description>&lt;p&gt;kernel: fs: fix UAF/GPF bug in nilfs_mdt_destroy kernel: mm: fix zswap writeback race condition kernel: pstore/ram: Check start of empty przs during init kernel: mm: kmem: fix a NULL pointer dereference in obj_stock_flush_required() kernel: ethtool: check device is present when getting link settings kernel: NFS: Fix filehandle bounds checking in nfs_fh_to_dentry()&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: fs: fix UAF/GPF bug in nilfs_mdt_destroy kernel: mm: fix zswap writeback race condition kernel: pstore/ram: Check start of empty przs during init kernel: mm: kmem: fix a NULL pointer dereference in obj_stock_flush_required() kernel: ethtool: check device is present when getting link settings kernel: NFS: Fix filehandle bounds checking in nfs_fh_to_dentry()&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2025:19886</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:03600-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:03600-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:03600-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-53331</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53331</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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, Ubuntu:16.04:LTS: linux-hwe-edge and 164 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: pstore/ram: Check start of empty przs during init After commit 30696378f68a (&amp;#34;pstore/ram: Do not treat empty buffers as valid&amp;#34;), initialization would assume a prz was valid after seeing that the buffer_size is zero (regardless of the buffer start position). This unchecked start value means it could be outside the bounds of the buffer, leading to future access panics when written to:  sysdump_panic_event+0x3b4/0x5b8  atomic_notifier_call_chain+0x54/0x90  panic+0x1c8/0x42c  die+0x29c/0x2a8  die_kernel_fault+0x68/0x78  __do_kernel_fault+0x1c4/0x1e0  do_bad_area+0x40/0x100  do_translation_fault+0x68/0x80  do_mem_abort+0x68/0xf8  el1_da+0x1c/0xc0  __raw_writeb+0x38/0x174  __memcpy_toio+0x40/0xac  persistent_ram_update+0x44/0x12c  persistent_ram_write+0x1a8/0x1b8  ramoops_pstore_write+0x198/0x1e8  pstore_console_write+0x94/0xe0  ... To avoid this, also check if the prz start is 0 during the initialization phase. If not, the next prz sanity check case will discover it (start &amp;gt; size) and zap the buffer back to a sane state. [kees: update commit log with backtrace and clarifications]&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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, Ubuntu:16.04:LTS: linux-hwe-edge and 164 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: pstore/ram: Check start of empty przs during init After commit 30696378f68a (&amp;#34;pstore/ram: Do not treat empty buffers as valid&amp;#34;), initialization would assume a prz was valid after seeing that the buffer_size is zero (regardless of the buffer start position). This unchecked start value means it could be outside the bounds of the buffer, leading to future access panics when written to:  sysdump_panic_event+0x3b4/0x5b8  atomic_notifier_call_chain+0x54/0x90  panic+0x1c8/0x42c  die+0x29c/0x2a8  die_kernel_fault+0x68/0x78  __do_kernel_fault+0x1c4/0x1e0  do_bad_area+0x40/0x100  do_translation_fault+0x68/0x80  do_mem_abort+0x68/0xf8  el1_da+0x1c/0xc0  __raw_writeb+0x38/0x174  __memcpy_toio+0x40/0xac  persistent_ram_update+0x44/0x12c  persistent_ram_write+0x1a8/0x1b8  ramoops_pstore_write+0x198/0x1e8  pstore_console_write+0x94/0xe0  ... To avoid this, also check if the prz start is 0 during the initialization phase. If not, the next prz sanity check case will discover it (start &amp;gt; size) and zap the buffer back to a sane state. [kees: update commit log with backtrace and clarifications]&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53331</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2077 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2077</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-2077</guid>
    </item>
  </channel>
</rss>
