<?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>Sun, 04 Oct 2026 05:32:48 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-14971</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-14971</link>
      <description>bdu:2025-14971</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-14971</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-38074</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-38074</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-2025-38074</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0698 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Certaines d'entre elles permettent à un…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0698</link>
      <description>certfr-2025-avi-0698</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0698</guid>
    </item>
    <item>
      <title>EUVD-2026-346905</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-346905</link>
      <description>EUVD-2026-346905</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-346905</guid>
    </item>
    <item>
      <title>fkie_cve-2025-38074</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-38074</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;vhost-scsi: protect vq-&amp;gt;log_used with vq-&amp;gt;mutex&lt;/p&gt;
&lt;p&gt;The vhost-scsi completion path may access vq-&amp;gt;log_base when vq-&amp;gt;log_used is
already set to false.&lt;/p&gt;
&lt;p&gt;vhost-thread                       QEMU-thread&lt;/p&gt;
&lt;p&gt;vhost_scsi_complete_cmd_work()
-&amp;gt; vhost_add_used()
   -&amp;gt; vhost_add_used_n()
      if (unlikely(vq-&amp;gt;log_used))
                                      QEMU disables vq-&amp;gt;log_used
                                      via VHOST_SET_VRING_ADDR.
                                      mutex_lock(&amp;amp;vq-&amp;gt;mutex);
                                      vq-&amp;gt;log_used = false now!
                                      mutex_unlock(&amp;amp;vq-&amp;gt;mutex);&lt;/p&gt;
&lt;p&gt;QEMU gfree(vq-&amp;gt;log_base)
        log_used()
        -&amp;gt; log_write(vq-&amp;gt;log_base)&lt;/p&gt;
&lt;p&gt;Assuming the VMM is QEMU. The vq-&amp;gt;log_base is from QEMU userpace and can be
reclaimed via gfree(). As a result, this causes invalid memory writes to
QEMU userspace.&lt;/p&gt;
&lt;p&gt;The control queue path has the same issue.&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;vhost-scsi: protect vq-&amp;gt;log_used with vq-&amp;gt;mutex&lt;/p&gt;
&lt;p&gt;The vhost-scsi completion path may access vq-&amp;gt;log_base when vq-&amp;gt;log_used is
already set to false.&lt;/p&gt;
&lt;p&gt;vhost-thread                       QEMU-thread&lt;/p&gt;
&lt;p&gt;vhost_scsi_complete_cmd_work()
-&amp;gt; vhost_add_used()
   -&amp;gt; vhost_add_used_n()
      if (unlikely(vq-&amp;gt;log_used))
                                      QEMU disables vq-&amp;gt;log_used
                                      via VHOST_SET_VRING_ADDR.
                                      mutex_lock(&amp;amp;vq-&amp;gt;mutex);
                                      vq-&amp;gt;log_used = false now!
                                      mutex_unlock(&amp;amp;vq-&amp;gt;mutex);&lt;/p&gt;
&lt;p&gt;QEMU gfree(vq-&amp;gt;log_base)
        log_used()
        -&amp;gt; log_write(vq-&amp;gt;log_base)&lt;/p&gt;
&lt;p&gt;Assuming the VMM is QEMU. The vq-&amp;gt;log_base is from QEMU userpace and can be
reclaimed via gfree(). As a result, this causes invalid memory writes to
QEMU userspace.&lt;/p&gt;
&lt;p&gt;The control queue path has the same issue.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-38074</guid>
    </item>
    <item>
      <title>GHSA-7p5h-9pp6-5wqc</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-7p5h-9pp6-5wqc</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;vhost-scsi: protect vq-&amp;gt;log_used with vq-&amp;gt;mutex&lt;/p&gt;
&lt;p&gt;The vhost-scsi completion path may access vq-&amp;gt;log_base when vq-&amp;gt;log_used is
already set to false.&lt;/p&gt;
&lt;p&gt;vhost-thread                       QEMU-thread&lt;/p&gt;
&lt;p&gt;vhost_scsi_complete_cmd_work()
-&amp;gt; vhost_add_used()
   -&amp;gt; vhost_add_used_n()
      if (unlikely(vq-&amp;gt;log_used))
                                      QEMU disables vq-&amp;gt;log_used
                                      via VHOST_SET_VRING_ADDR.
                                      mutex_lock(&amp;amp;vq-&amp;gt;mutex);
                                      vq-&amp;gt;log_used = false now!
                                      mutex_unlock(&amp;amp;vq-&amp;gt;mutex);&lt;/p&gt;
&lt;p&gt;QEMU gfree(vq-&amp;gt;log_base)
        log_used()
        -&amp;gt; log_write(vq-&amp;gt;log_base)&lt;/p&gt;
&lt;p&gt;Assuming the VMM is QEMU. The vq-&amp;gt;log_base is from QEMU userpace and can be
reclaimed via gfree(). As a result, this causes invalid memory writes to
QEMU userspace.&lt;/p&gt;
&lt;p&gt;The control queue path has the same issue.&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;vhost-scsi: protect vq-&amp;gt;log_used with vq-&amp;gt;mutex&lt;/p&gt;
&lt;p&gt;The vhost-scsi completion path may access vq-&amp;gt;log_base when vq-&amp;gt;log_used is
already set to false.&lt;/p&gt;
&lt;p&gt;vhost-thread                       QEMU-thread&lt;/p&gt;
&lt;p&gt;vhost_scsi_complete_cmd_work()
-&amp;gt; vhost_add_used()
   -&amp;gt; vhost_add_used_n()
      if (unlikely(vq-&amp;gt;log_used))
                                      QEMU disables vq-&amp;gt;log_used
                                      via VHOST_SET_VRING_ADDR.
                                      mutex_lock(&amp;amp;vq-&amp;gt;mutex);
                                      vq-&amp;gt;log_used = false now!
                                      mutex_unlock(&amp;amp;vq-&amp;gt;mutex);&lt;/p&gt;
&lt;p&gt;QEMU gfree(vq-&amp;gt;log_base)
        log_used()
        -&amp;gt; log_write(vq-&amp;gt;log_base)&lt;/p&gt;
&lt;p&gt;Assuming the VMM is QEMU. The vq-&amp;gt;log_base is from QEMU userpace and can be
reclaimed via gfree(). As a result, this causes invalid memory writes to
QEMU userspace.&lt;/p&gt;
&lt;p&gt;The control queue path has the same issue.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-7p5h-9pp6-5wqc</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-38074 — vhost-scsi: protect vq-&gt;log_used with vq-&gt;mutex</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-38074</link>
      <description>msrc_CVE-2025-38074</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-38074</guid>
    </item>
    <item>
      <title>OESA-2025-1729 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-1729</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):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:genirq/irqdesc: Prevent use-after-free in irq_find_at_or_after()irq_find_at_or_after() dereferences the interrupt descriptor which isreturned by mt_find() while neither holding sparse_irq_lock nor RCU readlock, which means the descriptor can be freed between mt_find() and thedereference:    CPU0                            CPU1    desc = mt_find()                                    delayed_free_desc(desc)    irq_desc_get_irq(desc)The use-after-free is reported by KASAN:    Call trace:     irq_get_next_irq+0x58/0x84     show_stat+0x638/0x824     seq_read_iter+0x158/0x4ec     proc_reg_read_iter+0x94/0x12c     vfs_read+0x1e0/0x2c8    Freed by task 4471:     slab_free_freelist_hook+0x174/0x1e0     __kmem_cache_free+0xa4/0x1dc     kfree+0x64/0x128     irq_kobj_release+0x28/0x3c     kobject_put+0xcc/0x1e0     delayed_free_desc+0x14/0x2c     rcu_do_batch+0x214/0x720Guard the access with a RCU read lock section.(CVE-2024-38385)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/lima: fix shared irq handling on driver remove&lt;/p&gt;
&lt;p&gt;lima uses a shared interrupt, so the interrupt handlers must be prepared
to be called at any time. At driver removal time, the clocks are
disabled early and the interrupts stay registered until the very end of
the remove process due to the devm usage.
This is potentially a bug as the interrupts access…&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):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:genirq/irqdesc: Prevent use-after-free in irq_find_at_or_after()irq_find_at_or_after() dereferences the interrupt descriptor which isreturned by mt_find() while neither holding sparse_irq_lock nor RCU readlock, which means the descriptor can be freed between mt_find() and thedereference:    CPU0                            CPU1    desc = mt_find()                                    delayed_free_desc(desc)    irq_desc_get_irq(desc)The use-after-free is reported by KASAN:    Call trace:     irq_get_next_irq+0x58/0x84     show_stat+0x638/0x824     seq_read_iter+0x158/0x4ec     proc_reg_read_iter+0x94/0x12c     vfs_read+0x1e0/0x2c8    Freed by task 4471:     slab_free_freelist_hook+0x174/0x1e0     __kmem_cache_free+0xa4/0x1dc     kfree+0x64/0x128     irq_kobj_release+0x28/0x3c     kobject_put+0xcc/0x1e0     delayed_free_desc+0x14/0x2c     rcu_do_batch+0x214/0x720Guard the access with a RCU read lock section.(CVE-2024-38385)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/lima: fix shared irq handling on driver remove&lt;/p&gt;
&lt;p&gt;lima uses a shared interrupt, so the interrupt handlers must be prepared
to be called at any time. At driver removal time, the clocks are
disabled early and the interrupts stay registered until the very end of
the remove process due to the devm usage.
This is potentially a bug as the interrupts access…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-1729</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:02846-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:02846-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:02846-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-38074</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-38074</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 212 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: protect vq-&amp;gt;log_used with vq-&amp;gt;mutex The vhost-scsi completion path may access vq-&amp;gt;log_base when vq-&amp;gt;log_used is already set to false.     vhost-thread                       QEMU-thread vhost_scsi_complete_cmd_work() -&amp;gt; vhost_add_used()    -&amp;gt; vhost_add_used_n()       if (unlikely(vq-&amp;gt;log_used))                                       QEMU disables vq-&amp;gt;log_used                                       via VHOST_SET_VRING_ADDR.                                       mutex_lock(&amp;amp;vq-&amp;gt;mutex);                                       vq-&amp;gt;log_used = false now!                                       mutex_unlock(&amp;amp;vq-&amp;gt;mutex); 				      QEMU gfree(vq-&amp;gt;log_base)         log_used()         -&amp;gt; log_write(vq-&amp;gt;log_base) Assuming the VMM is QEMU. The vq-&amp;gt;log_base is from QEMU userpace and can be reclaimed via gfree(). As a result, this causes invalid memory writes to QEMU userspace. The control queue path has the same issue.&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 212 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: protect vq-&amp;gt;log_used with vq-&amp;gt;mutex The vhost-scsi completion path may access vq-&amp;gt;log_base when vq-&amp;gt;log_used is already set to false.     vhost-thread                       QEMU-thread vhost_scsi_complete_cmd_work() -&amp;gt; vhost_add_used()    -&amp;gt; vhost_add_used_n()       if (unlikely(vq-&amp;gt;log_used))                                       QEMU disables vq-&amp;gt;log_used                                       via VHOST_SET_VRING_ADDR.                                       mutex_lock(&amp;amp;vq-&amp;gt;mutex);                                       vq-&amp;gt;log_used = false now!                                       mutex_unlock(&amp;amp;vq-&amp;gt;mutex); 				      QEMU gfree(vq-&amp;gt;log_base)         log_used()         -&amp;gt; log_write(vq-&amp;gt;log_base) Assuming the VMM is QEMU. The vq-&amp;gt;log_base is from QEMU userpace and can be reclaimed via gfree(). As a result, this causes invalid memory writes to QEMU userspace. The control queue path has the same issue.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-38074</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-1350 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1350</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-2025-1350</guid>
    </item>
  </channel>
</rss>
