<?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:24:49 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-03644</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-03644</link>
      <description>bdu:2026-03644</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-03644</guid>
    </item>
    <item>
      <title>BELL-CVE-2023-53698</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2023-53698</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-53698</guid>
    </item>
    <item>
      <title>certfr-2025-avi-1009 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Elles permettent à un attaquant de provoqu…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-1009</link>
      <description>certfr-2025-avi-1009</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-1009</guid>
    </item>
    <item>
      <title>EUVD-2026-345291</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-345291</link>
      <description>EUVD-2026-345291</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-345291</guid>
    </item>
    <item>
      <title>fkie_cve-2023-53698</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-53698</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;xsk: fix refcount underflow in error path&lt;/p&gt;
&lt;p&gt;Fix a refcount underflow problem reported by syzbot that can happen
when a system is running out of memory. If xp_alloc_tx_descs() fails,
and it can only fail due to not having enough memory, then the error
path is triggered. In this error path, the refcount of the pool is
decremented as it has incremented before. However, the reference to
the pool in the socket was not nulled. This means that when the socket
is closed later, the socket teardown logic will think that there is a
pool attached to the socket and try to decrease the refcount again,
leading to a refcount underflow.&lt;/p&gt;
&lt;p&gt;I chose this fix as it involved adding just a single line. Another
option would have been to move xp_get_pool() and the assignment of
xs-&amp;gt;pool to after the if-statement and using xs_umem-&amp;gt;pool instead of
xs-&amp;gt;pool in the whole if-statement resulting in somewhat simpler code,
but this would have led to much more churn in the code base perhaps
making it harder to backport.&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;xsk: fix refcount underflow in error path&lt;/p&gt;
&lt;p&gt;Fix a refcount underflow problem reported by syzbot that can happen
when a system is running out of memory. If xp_alloc_tx_descs() fails,
and it can only fail due to not having enough memory, then the error
path is triggered. In this error path, the refcount of the pool is
decremented as it has incremented before. However, the reference to
the pool in the socket was not nulled. This means that when the socket
is closed later, the socket teardown logic will think that there is a
pool attached to the socket and try to decrease the refcount again,
leading to a refcount underflow.&lt;/p&gt;
&lt;p&gt;I chose this fix as it involved adding just a single line. Another
option would have been to move xp_get_pool() and the assignment of
xs-&amp;gt;pool to after the if-statement and using xs_umem-&amp;gt;pool instead of
xs-&amp;gt;pool in the whole if-statement resulting in somewhat simpler code,
but this would have led to much more churn in the code base perhaps
making it harder to backport.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-53698</guid>
    </item>
    <item>
      <title>GHSA-f7vc-g3xh-9xx2</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-f7vc-g3xh-9xx2</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;xsk: fix refcount underflow in error path&lt;/p&gt;
&lt;p&gt;Fix a refcount underflow problem reported by syzbot that can happen
when a system is running out of memory. If xp_alloc_tx_descs() fails,
and it can only fail due to not having enough memory, then the error
path is triggered. In this error path, the refcount of the pool is
decremented as it has incremented before. However, the reference to
the pool in the socket was not nulled. This means that when the socket
is closed later, the socket teardown logic will think that there is a
pool attached to the socket and try to decrease the refcount again,
leading to a refcount underflow.&lt;/p&gt;
&lt;p&gt;I chose this fix as it involved adding just a single line. Another
option would have been to move xp_get_pool() and the assignment of
xs-&amp;gt;pool to after the if-statement and using xs_umem-&amp;gt;pool instead of
xs-&amp;gt;pool in the whole if-statement resulting in somewhat simpler code,
but this would have led to much more churn in the code base perhaps
making it harder to backport.&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;xsk: fix refcount underflow in error path&lt;/p&gt;
&lt;p&gt;Fix a refcount underflow problem reported by syzbot that can happen
when a system is running out of memory. If xp_alloc_tx_descs() fails,
and it can only fail due to not having enough memory, then the error
path is triggered. In this error path, the refcount of the pool is
decremented as it has incremented before. However, the reference to
the pool in the socket was not nulled. This means that when the socket
is closed later, the socket teardown logic will think that there is a
pool attached to the socket and try to decrease the refcount again,
leading to a refcount underflow.&lt;/p&gt;
&lt;p&gt;I chose this fix as it involved adding just a single line. Another
option would have been to move xp_get_pool() and the assignment of
xs-&amp;gt;pool to after the if-statement and using xs_umem-&amp;gt;pool instead of
xs-&amp;gt;pool in the whole if-statement resulting in somewhat simpler code,
but this would have led to much more churn in the code base perhaps
making it harder to backport.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-f7vc-g3xh-9xx2</guid>
    </item>
    <item>
      <title>RHSA-2024:3138 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2024:3138</link>
      <description>&lt;p&gt;kernel: OOB writes in parse_hid_report_descriptor in drivers/input/tablet/gtco.c kernel: out of bounds read in drivers/media/usb/dvb-usb/technisat-usb2.c kernel: use-after-free in read in vt_do_kdgkb_ioctl kernel: a race out-of-bound read in vt kernel: improper input validation may lead to privilege escalation kernel: Linux ebpf logic vulnerability leads to critical memory read and write gaining root privileges kernel: use-after-free in l1oip timer handlers kernel: local privileges escalation in kernel/bpf/verifier.c kernel: integer overflow in l2cap_config_req() in net/bluetooth/l2cap_core.c kernel: Bluetooth: L2CAP: Fix u8 overflow kernel: highmem: fix checks in __kmap_local_sched_{in,out} kernel: mm/slub: add missing TID updates on slab deactivation kernel: VMCI: Use threaded irqs instead of tasklets kernel: ACPI: APEI: Fix integer overflow in ghes_estatus_pool_init() kernel: tty: n_gsm: add sanity check for gsm-&amp;gt;receive in gsm_receive_buf() kernel: tty: n_gsm: fix deadlock and link starvation in outgoing data path kernel: jbd2: fix assertion &amp;#39;jh-&amp;gt;b_frozen_data == NULL&amp;#39; failure when journal aborted kernel: usb: host: Fix refcount leak in ehci_hcd_ppc_of_probe kernel: media: dvbdev: adopts refcnt to avoid UAF kernel: ext4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline kernel: ACPI: processor: idle: Check acpi_fetch_acpi_dev() return value kernel: ext4: fix null-ptr-deref in ext4_write_info kernel: ext4: init quota for &amp;#39;old.inode&amp;#39; in &amp;#39;ext4_rename&amp;#39; kern…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: OOB writes in parse_hid_report_descriptor in drivers/input/tablet/gtco.c kernel: out of bounds read in drivers/media/usb/dvb-usb/technisat-usb2.c kernel: use-after-free in read in vt_do_kdgkb_ioctl kernel: a race out-of-bound read in vt kernel: improper input validation may lead to privilege escalation kernel: Linux ebpf logic vulnerability leads to critical memory read and write gaining root privileges kernel: use-after-free in l1oip timer handlers kernel: local privileges escalation in kernel/bpf/verifier.c kernel: integer overflow in l2cap_config_req() in net/bluetooth/l2cap_core.c kernel: Bluetooth: L2CAP: Fix u8 overflow kernel: highmem: fix checks in __kmap_local_sched_{in,out} kernel: mm/slub: add missing TID updates on slab deactivation kernel: VMCI: Use threaded irqs instead of tasklets kernel: ACPI: APEI: Fix integer overflow in ghes_estatus_pool_init() kernel: tty: n_gsm: add sanity check for gsm-&amp;gt;receive in gsm_receive_buf() kernel: tty: n_gsm: fix deadlock and link starvation in outgoing data path kernel: jbd2: fix assertion &amp;#39;jh-&amp;gt;b_frozen_data == NULL&amp;#39; failure when journal aborted kernel: usb: host: Fix refcount leak in ehci_hcd_ppc_of_probe kernel: media: dvbdev: adopts refcnt to avoid UAF kernel: ext4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline kernel: ACPI: processor: idle: Check acpi_fetch_acpi_dev() return value kernel: ext4: fix null-ptr-deref in ext4_write_info kernel: ext4: init quota for &amp;#39;old.inode&amp;#39; in &amp;#39;ext4_rename&amp;#39; kern…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2024:3138</guid>
    </item>
    <item>
      <title>RXSA-2024:3138 — Moderate: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/rxsa-2024:3138</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Rocky Linux:8: kernel&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;
&lt;p&gt;Additional Changes:&lt;/p&gt;
&lt;p&gt;For detailed information on changes in this release, see the Rocky Linux SIG Cloud 8.10 Release Notes linked from the References section.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Rocky Linux:8: kernel&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;
&lt;p&gt;Additional Changes:&lt;/p&gt;
&lt;p&gt;For detailed information on changes in this release, see the Rocky Linux SIG Cloud 8.10 Release Notes linked from the References section.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rxsa-2024:3138</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:21040-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:21040-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:21040-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-53698</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53698</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 108 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: xsk: fix refcount underflow in error path Fix a refcount underflow problem reported by syzbot that can happen when a system is running out of memory. If xp_alloc_tx_descs() fails, and it can only fail due to not having enough memory, then the error path is triggered. In this error path, the refcount of the pool is decremented as it has incremented before. However, the reference to the pool in the socket was not nulled. This means that when the socket is closed later, the socket teardown logic will think that there is a pool attached to the socket and try to decrease the refcount again, leading to a refcount underflow. I chose this fix as it involved adding just a single line. Another option would have been to move xp_get_pool() and the assignment of xs-&amp;gt;pool to after the if-statement and using xs_umem-&amp;gt;pool instead of xs-&amp;gt;pool in the whole if-statement resulting in somewhat simpler code, but this would have led to much more churn in the code base perhaps making it harder to backport.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 108 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: xsk: fix refcount underflow in error path Fix a refcount underflow problem reported by syzbot that can happen when a system is running out of memory. If xp_alloc_tx_descs() fails, and it can only fail due to not having enough memory, then the error path is triggered. In this error path, the refcount of the pool is decremented as it has incremented before. However, the reference to the pool in the socket was not nulled. This means that when the socket is closed later, the socket teardown logic will think that there is a pool attached to the socket and try to decrease the refcount again, leading to a refcount underflow. I chose this fix as it involved adding just a single line. Another option would have been to move xp_get_pool() and the assignment of xs-&amp;gt;pool to after the if-statement and using xs_umem-&amp;gt;pool instead of xs-&amp;gt;pool in the whole if-statement resulting in somewhat simpler code, but this would have led to much more churn in the code base perhaps making it harder to backport.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53698</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2394 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2394</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff oder andere, nicht näher spezifizierte Angriffe durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff oder andere, nicht näher spezifizierte Angriffe durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2394</guid>
    </item>
  </channel>
</rss>
