<?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 06:51:38 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-03447</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-03447</link>
      <description>bdu:2025-03447</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-03447</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-40953</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-40953</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-40953</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0613 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Elles permettent à un attaquant de provo…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0613</link>
      <description>certfr-2024-avi-0613</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0613</guid>
    </item>
    <item>
      <title>EUVD-2026-345882</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-345882</link>
      <description>EUVD-2026-345882</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-345882</guid>
    </item>
    <item>
      <title>fkie_cve-2024-40953</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-40953</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()&lt;/p&gt;
&lt;p&gt;Use {READ,WRITE}_ONCE() to access kvm-&amp;gt;last_boosted_vcpu to ensure the
loads and stores are atomic.  In the extremely unlikely scenario the
compiler tears the stores, it&amp;#39;s theoretically possible for KVM to attempt
to get a vCPU using an out-of-bounds index, e.g. if the write is split
into multiple 8-bit stores, and is paired with a 32-bit load on a VM with
257 vCPUs:&lt;/p&gt;
&lt;p&gt;CPU0                              CPU1
  last_boosted_vcpu = 0xff;&lt;/p&gt;
&lt;p&gt;(last_boosted_vcpu = 0x100)
                                    last_boosted_vcpu[15:8] = 0x01;
  i = (last_boosted_vcpu = 0x1ff)
                                    last_boosted_vcpu[7:0] = 0x00;&lt;/p&gt;
&lt;p&gt;vcpu = kvm-&amp;gt;vcpu_array[0x1ff];&lt;/p&gt;
&lt;p&gt;As detected by KCSAN:&lt;/p&gt;
&lt;p&gt;BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm]&lt;/p&gt;
&lt;p&gt;write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16:
  kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm
  handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel
  vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?
		 arch/x86/kvm/vmx/vmx.c:6606) kvm_intel
  vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm
  kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm
  kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm
  __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)
  __x64_sys_ioctl (fs/ioctl.c…&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;KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()&lt;/p&gt;
&lt;p&gt;Use {READ,WRITE}_ONCE() to access kvm-&amp;gt;last_boosted_vcpu to ensure the
loads and stores are atomic.  In the extremely unlikely scenario the
compiler tears the stores, it&amp;#39;s theoretically possible for KVM to attempt
to get a vCPU using an out-of-bounds index, e.g. if the write is split
into multiple 8-bit stores, and is paired with a 32-bit load on a VM with
257 vCPUs:&lt;/p&gt;
&lt;p&gt;CPU0                              CPU1
  last_boosted_vcpu = 0xff;&lt;/p&gt;
&lt;p&gt;(last_boosted_vcpu = 0x100)
                                    last_boosted_vcpu[15:8] = 0x01;
  i = (last_boosted_vcpu = 0x1ff)
                                    last_boosted_vcpu[7:0] = 0x00;&lt;/p&gt;
&lt;p&gt;vcpu = kvm-&amp;gt;vcpu_array[0x1ff];&lt;/p&gt;
&lt;p&gt;As detected by KCSAN:&lt;/p&gt;
&lt;p&gt;BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm]&lt;/p&gt;
&lt;p&gt;write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16:
  kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm
  handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel
  vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?
		 arch/x86/kvm/vmx/vmx.c:6606) kvm_intel
  vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm
  kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm
  kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm
  __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)
  __x64_sys_ioctl (fs/ioctl.c…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-40953</guid>
    </item>
    <item>
      <title>GHSA-j7wr-633c-vhmr</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-j7wr-633c-vhmr</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()&lt;/p&gt;
&lt;p&gt;Use {READ,WRITE}_ONCE() to access kvm-&amp;gt;last_boosted_vcpu to ensure the
loads and stores are atomic.  In the extremely unlikely scenario the
compiler tears the stores, it&amp;#39;s theoretically possible for KVM to attempt
to get a vCPU using an out-of-bounds index, e.g. if the write is split
into multiple 8-bit stores, and is paired with a 32-bit load on a VM with
257 vCPUs:&lt;/p&gt;
&lt;p&gt;CPU0                              CPU1
  last_boosted_vcpu = 0xff;&lt;/p&gt;
&lt;p&gt;(last_boosted_vcpu = 0x100)
                                    last_boosted_vcpu[15:8] = 0x01;
  i = (last_boosted_vcpu = 0x1ff)
                                    last_boosted_vcpu[7:0] = 0x00;&lt;/p&gt;
&lt;p&gt;vcpu = kvm-&amp;gt;vcpu_array[0x1ff];&lt;/p&gt;
&lt;p&gt;As detected by KCSAN:&lt;/p&gt;
&lt;p&gt;BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm]&lt;/p&gt;
&lt;p&gt;write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16:
  kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm
  handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel
  vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?
		 arch/x86/kvm/vmx/vmx.c:6606) kvm_intel
  vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm
  kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm
  kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm
  __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)
  __x64_sys_ioctl (fs/ioctl.c…&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;KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()&lt;/p&gt;
&lt;p&gt;Use {READ,WRITE}_ONCE() to access kvm-&amp;gt;last_boosted_vcpu to ensure the
loads and stores are atomic.  In the extremely unlikely scenario the
compiler tears the stores, it&amp;#39;s theoretically possible for KVM to attempt
to get a vCPU using an out-of-bounds index, e.g. if the write is split
into multiple 8-bit stores, and is paired with a 32-bit load on a VM with
257 vCPUs:&lt;/p&gt;
&lt;p&gt;CPU0                              CPU1
  last_boosted_vcpu = 0xff;&lt;/p&gt;
&lt;p&gt;(last_boosted_vcpu = 0x100)
                                    last_boosted_vcpu[15:8] = 0x01;
  i = (last_boosted_vcpu = 0x1ff)
                                    last_boosted_vcpu[7:0] = 0x00;&lt;/p&gt;
&lt;p&gt;vcpu = kvm-&amp;gt;vcpu_array[0x1ff];&lt;/p&gt;
&lt;p&gt;As detected by KCSAN:&lt;/p&gt;
&lt;p&gt;BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm]&lt;/p&gt;
&lt;p&gt;write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16:
  kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm
  handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel
  vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?
		 arch/x86/kvm/vmx/vmx.c:6606) kvm_intel
  vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm
  kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm
  kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm
  __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)
  __x64_sys_ioctl (fs/ioctl.c…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-j7wr-633c-vhmr</guid>
    </item>
    <item>
      <title>OESA-2024-1960 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1960</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):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
efi: libstub: only free priv.runtime_map when allocated&#13;
&#13;
priv.runtime_map is only allocated when efi_novamap is not set.
Otherwise, it is an uninitialized value.  In the error path, it is freed
unconditionally.  Avoid passing an uninitialized value to free_pool.
Free priv.runtime_map only when it was allocated.&#13;
&#13;
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.(CVE-2024-33619)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
fpga: region: add owner module and take its refcount&#13;
&#13;
The current implementation of the fpga region assumes that the low-level
module registers a driver for the parent device and uses its owner pointer
to take the module&amp;amp;apos;s refcount. This approach is problematic since it can
lead to a null pointer dereference while attempting to get the region
during programming if the parent device does not have a driver.&#13;
&#13;
To address this problem, add a module owner pointer to the fpga_region
struct and use it to take the module&amp;amp;apos;s refcount. Modify the functions for
registering a region to take an additional owner module parameter and
rename them to avoid conflicts. Use the old function names for helper
macros that automatically set the module that registers the region as the
owner. This ensures compatibility with existing low…&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):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
efi: libstub: only free priv.runtime_map when allocated&#13;
&#13;
priv.runtime_map is only allocated when efi_novamap is not set.
Otherwise, it is an uninitialized value.  In the error path, it is freed
unconditionally.  Avoid passing an uninitialized value to free_pool.
Free priv.runtime_map only when it was allocated.&#13;
&#13;
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.(CVE-2024-33619)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
fpga: region: add owner module and take its refcount&#13;
&#13;
The current implementation of the fpga region assumes that the low-level
module registers a driver for the parent device and uses its owner pointer
to take the module&amp;amp;apos;s refcount. This approach is problematic since it can
lead to a null pointer dereference while attempting to get the region
during programming if the parent device does not have a driver.&#13;
&#13;
To address this problem, add a module owner pointer to the fpga_region
struct and use it to take the module&amp;amp;apos;s refcount. Modify the functions for
registering a region to take an additional owner module parameter and
rename them to avoid conflicts. Use the old function names for helper
macros that automatically set the module that registers the region as the
owner. This ensures compatibility with existing low…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1960</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:2802-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:2802-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:2802-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-40953</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-40953</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 184 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin() Use {READ,WRITE}_ONCE() to access kvm-&amp;gt;last_boosted_vcpu to ensure the loads and stores are atomic.  In the extremely unlikely scenario the compiler tears the stores, it&amp;#39;s theoretically possible for KVM to attempt to get a vCPU using an out-of-bounds index, e.g. if the write is split into multiple 8-bit stores, and is paired with a 32-bit load on a VM with 257 vCPUs:   CPU0                              CPU1   last_boosted_vcpu = 0xff;                                     (last_boosted_vcpu = 0x100)                                     last_boosted_vcpu[15:8] = 0x01;   i = (last_boosted_vcpu = 0x1ff)                                     last_boosted_vcpu[7:0] = 0x00;   vcpu = kvm-&amp;gt;vcpu_array[0x1ff]; As detected by KCSAN:   BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm]   write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16:   kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm   handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel   vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? 		 arch/x86/kvm/vmx/vmx.c:6606) kvm_intel   vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm   kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm   kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm   __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)   __x64_sys_ioctl (fs/ioctl.c:890)…&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 184 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin() Use {READ,WRITE}_ONCE() to access kvm-&amp;gt;last_boosted_vcpu to ensure the loads and stores are atomic.  In the extremely unlikely scenario the compiler tears the stores, it&amp;#39;s theoretically possible for KVM to attempt to get a vCPU using an out-of-bounds index, e.g. if the write is split into multiple 8-bit stores, and is paired with a 32-bit load on a VM with 257 vCPUs:   CPU0                              CPU1   last_boosted_vcpu = 0xff;                                     (last_boosted_vcpu = 0x100)                                     last_boosted_vcpu[15:8] = 0x01;   i = (last_boosted_vcpu = 0x1ff)                                     last_boosted_vcpu[7:0] = 0x00;   vcpu = kvm-&amp;gt;vcpu_array[0x1ff]; As detected by KCSAN:   BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm]   write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16:   kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm   handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel   vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? 		 arch/x86/kvm/vmx/vmx.c:6606) kvm_intel   vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm   kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm   kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm   __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)   __x64_sys_ioctl (fs/ioctl.c:890)…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-40953</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-1607 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1607</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um seine Privilegien zu erweitern, einen Denial-of-Service-Zustand zu erzeugen, vertrauliche Informationen offenzulegen oder einen unspezifischen Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um seine Privilegien zu erweitern, einen Denial-of-Service-Zustand zu erzeugen, vertrauliche Informationen offenzulegen oder einen unspezifischen Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1607</guid>
    </item>
  </channel>
</rss>
