<?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 21:55:02 +0000</lastBuildDate>
    <item>
      <title>bdu:2024-09204</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2024-09204</link>
      <description>bdu:2024-09204</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2024-09204</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-26813</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-26813</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-26813</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0334 — De multiples vulnérabilités ont été découvertes dans &lt;span
class="textit"&gt;le noyau Linux de Debian&lt;/span&gt;. Elles permet…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0334</link>
      <description>certfr-2024-avi-0334</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0334</guid>
    </item>
    <item>
      <title>EUVD-2026-312614</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-312614</link>
      <description>EUVD-2026-312614</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-312614</guid>
    </item>
    <item>
      <title>fkie_cve-2024-26813</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-26813</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;vfio/platform: Create persistent IRQ handlers&lt;/p&gt;
&lt;p&gt;The vfio-platform SET_IRQS ioctl currently allows loopback triggering of
an interrupt before a signaling eventfd has been configured by the user,
which thereby allows a NULL pointer dereference.&lt;/p&gt;
&lt;p&gt;Rather than register the IRQ relative to a valid trigger, register all
IRQs in a disabled state in the device open path.  This allows mask
operations on the IRQ to nest within the overall enable state governed
by a valid eventfd signal.  This decouples @masked, protected by the
@locked spinlock from @trigger, protected via the @igate mutex.&lt;/p&gt;
&lt;p&gt;In doing so, it&amp;#39;s guaranteed that changes to @trigger cannot race the
IRQ handlers because the IRQ handler is synchronously disabled before
modifying the trigger, and loopback triggering of the IRQ via ioctl is
safe due to serialization with trigger changes via igate.&lt;/p&gt;
&lt;p&gt;For compatibility, request_irq() failures are maintained to be local to
the SET_IRQS ioctl rather than a fatal error in the open device path.
This allows, for example, a userspace driver with polling mode support
to continue to work regardless of moving the request_irq() call site.
This necessarily blocks all SET_IRQS access to the failed index.&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;vfio/platform: Create persistent IRQ handlers&lt;/p&gt;
&lt;p&gt;The vfio-platform SET_IRQS ioctl currently allows loopback triggering of
an interrupt before a signaling eventfd has been configured by the user,
which thereby allows a NULL pointer dereference.&lt;/p&gt;
&lt;p&gt;Rather than register the IRQ relative to a valid trigger, register all
IRQs in a disabled state in the device open path.  This allows mask
operations on the IRQ to nest within the overall enable state governed
by a valid eventfd signal.  This decouples @masked, protected by the
@locked spinlock from @trigger, protected via the @igate mutex.&lt;/p&gt;
&lt;p&gt;In doing so, it&amp;#39;s guaranteed that changes to @trigger cannot race the
IRQ handlers because the IRQ handler is synchronously disabled before
modifying the trigger, and loopback triggering of the IRQ via ioctl is
safe due to serialization with trigger changes via igate.&lt;/p&gt;
&lt;p&gt;For compatibility, request_irq() failures are maintained to be local to
the SET_IRQS ioctl rather than a fatal error in the open device path.
This allows, for example, a userspace driver with polling mode support
to continue to work regardless of moving the request_irq() call site.
This necessarily blocks all SET_IRQS access to the failed index.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-26813</guid>
    </item>
    <item>
      <title>GHSA-69h6-fpm9-fc3r</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-69h6-fpm9-fc3r</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;vfio/platform: Create persistent IRQ handlers&lt;/p&gt;
&lt;p&gt;The vfio-platform SET_IRQS ioctl currently allows loopback triggering of
an interrupt before a signaling eventfd has been configured by the user,
which thereby allows a NULL pointer dereference.&lt;/p&gt;
&lt;p&gt;Rather than register the IRQ relative to a valid trigger, register all
IRQs in a disabled state in the device open path.  This allows mask
operations on the IRQ to nest within the overall enable state governed
by a valid eventfd signal.  This decouples @masked, protected by the
@locked spinlock from @trigger, protected via the @igate mutex.&lt;/p&gt;
&lt;p&gt;In doing so, it&amp;#39;s guaranteed that changes to @trigger cannot race the
IRQ handlers because the IRQ handler is synchronously disabled before
modifying the trigger, and loopback triggering of the IRQ via ioctl is
safe due to serialization with trigger changes via igate.&lt;/p&gt;
&lt;p&gt;For compatibility, request_irq() failures are maintained to be local to
the SET_IRQS ioctl rather than a fatal error in the open device path.
This allows, for example, a userspace driver with polling mode support
to continue to work regardless of moving the request_irq() call site.
This necessarily blocks all SET_IRQS access to the failed index.&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;vfio/platform: Create persistent IRQ handlers&lt;/p&gt;
&lt;p&gt;The vfio-platform SET_IRQS ioctl currently allows loopback triggering of
an interrupt before a signaling eventfd has been configured by the user,
which thereby allows a NULL pointer dereference.&lt;/p&gt;
&lt;p&gt;Rather than register the IRQ relative to a valid trigger, register all
IRQs in a disabled state in the device open path.  This allows mask
operations on the IRQ to nest within the overall enable state governed
by a valid eventfd signal.  This decouples @masked, protected by the
@locked spinlock from @trigger, protected via the @igate mutex.&lt;/p&gt;
&lt;p&gt;In doing so, it&amp;#39;s guaranteed that changes to @trigger cannot race the
IRQ handlers because the IRQ handler is synchronously disabled before
modifying the trigger, and loopback triggering of the IRQ via ioctl is
safe due to serialization with trigger changes via igate.&lt;/p&gt;
&lt;p&gt;For compatibility, request_irq() failures are maintained to be local to
the SET_IRQS ioctl rather than a fatal error in the open device path.
This allows, for example, a userspace driver with polling mode support
to continue to work regardless of moving the request_irq() call site.
This necessarily blocks all SET_IRQS access to the failed index.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-69h6-fpm9-fc3r</guid>
    </item>
    <item>
      <title>gsd-2024-26813</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2024-26813</link>
      <description>gsd-2024-26813</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2024-26813</guid>
    </item>
    <item>
      <title>OESA-2024-1617 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1617</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.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:&#13;
&#13;
x86/kvm: Disable kvmclock on all CPUs on shutdown&#13;
&#13;
Currenly, we disable kvmclock from machine_shutdown() hook and this
only happens for boot CPU. We need to disable it for all CPUs to
guard against memory corruption e.g. on restore from hibernate.&#13;
&#13;
Note, writing &amp;amp;apos;0&amp;amp;apos; to kvmclock MSR doesn&amp;amp;apos;t clear memory location, it
just prevents hypervisor from updating the location so for the short
while after write and while CPU is still alive, the clock remains usable
and correct so we don&amp;amp;apos;t need to switch to some other clocksource.(CVE-2021-47110)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
i40e: Fix NULL ptr dereference on VSI filter sync&#13;
&#13;
Remove the reason of null pointer dereference in sync VSI filters.
Added new I40E_VSI_RELEASING flag to signalize deleting and releasing
of VSI resources to sync this thread with sync filters subtask.
Without this patch it is possible to start update the VSI filter list
after VSI is removed, that&amp;amp;apos;s causing a kernel oops.(CVE-2021-47184)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
erofs: fix pcluster use-after-free on UP platforms&#13;
&#13;
During stress testing with CONFIG_SMP disabled, KASAN reports as below:&#13;
&#13;
==================================================================
BUG: KASAN: use-after-free in __mutex_lock+0xe…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.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:&#13;
&#13;
x86/kvm: Disable kvmclock on all CPUs on shutdown&#13;
&#13;
Currenly, we disable kvmclock from machine_shutdown() hook and this
only happens for boot CPU. We need to disable it for all CPUs to
guard against memory corruption e.g. on restore from hibernate.&#13;
&#13;
Note, writing &amp;amp;apos;0&amp;amp;apos; to kvmclock MSR doesn&amp;amp;apos;t clear memory location, it
just prevents hypervisor from updating the location so for the short
while after write and while CPU is still alive, the clock remains usable
and correct so we don&amp;amp;apos;t need to switch to some other clocksource.(CVE-2021-47110)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
i40e: Fix NULL ptr dereference on VSI filter sync&#13;
&#13;
Remove the reason of null pointer dereference in sync VSI filters.
Added new I40E_VSI_RELEASING flag to signalize deleting and releasing
of VSI resources to sync this thread with sync filters subtask.
Without this patch it is possible to start update the VSI filter list
after VSI is removed, that&amp;amp;apos;s causing a kernel oops.(CVE-2021-47184)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
erofs: fix pcluster use-after-free on UP platforms&#13;
&#13;
During stress testing with CONFIG_SMP disabled, KASAN reports as below:&#13;
&#13;
==================================================================
BUG: KASAN: use-after-free in __mutex_lock+0xe…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1617</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:2360-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:2360-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:2360-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-26813</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-26813</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 170 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: vfio/platform: Create persistent IRQ handlers The vfio-platform SET_IRQS ioctl currently allows loopback triggering of an interrupt before a signaling eventfd has been configured by the user, which thereby allows a NULL pointer dereference. Rather than register the IRQ relative to a valid trigger, register all IRQs in a disabled state in the device open path.  This allows mask operations on the IRQ to nest within the overall enable state governed by a valid eventfd signal.  This decouples @masked, protected by the @locked spinlock from @trigger, protected via the @igate mutex. In doing so, it&amp;#39;s guaranteed that changes to @trigger cannot race the IRQ handlers because the IRQ handler is synchronously disabled before modifying the trigger, and loopback triggering of the IRQ via ioctl is safe due to serialization with trigger changes via igate. For compatibility, request_irq() failures are maintained to be local to the SET_IRQS ioctl rather than a fatal error in the open device path. This allows, for example, a userspace driver with polling mode support to continue to work regardless of moving the request_irq() call site. This necessarily blocks all SET_IRQS access to the failed index.&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 170 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: vfio/platform: Create persistent IRQ handlers The vfio-platform SET_IRQS ioctl currently allows loopback triggering of an interrupt before a signaling eventfd has been configured by the user, which thereby allows a NULL pointer dereference. Rather than register the IRQ relative to a valid trigger, register all IRQs in a disabled state in the device open path.  This allows mask operations on the IRQ to nest within the overall enable state governed by a valid eventfd signal.  This decouples @masked, protected by the @locked spinlock from @trigger, protected via the @igate mutex. In doing so, it&amp;#39;s guaranteed that changes to @trigger cannot race the IRQ handlers because the IRQ handler is synchronously disabled before modifying the trigger, and loopback triggering of the IRQ via ioctl is safe due to serialization with trigger changes via igate. For compatibility, request_irq() failures are maintained to be local to the SET_IRQS ioctl rather than a fatal error in the open device path. This allows, for example, a userspace driver with polling mode support to continue to work regardless of moving the request_irq() call site. This necessarily blocks all SET_IRQS access to the failed index.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-26813</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-0804 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0804</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0804</guid>
    </item>
  </channel>
</rss>
