<?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 01:01:18 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-12197</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-12197</link>
      <description>bdu:2025-12197</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-12197</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-21779</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-21779</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-21779</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0277 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Elles permettent à un attaquant de p…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0277</link>
      <description>certfr-2025-avi-0277</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0277</guid>
    </item>
    <item>
      <title>EUVD-2026-314039</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-314039</link>
      <description>EUVD-2026-314039</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-314039</guid>
    </item>
    <item>
      <title>fkie_cve-2025-21779</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-21779</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: x86: Reject Hyper-V&amp;#39;s SEND_IPI hypercalls if local APIC isn&amp;#39;t in-kernel&lt;/p&gt;
&lt;p&gt;Advertise support for Hyper-V&amp;#39;s SEND_IPI and SEND_IPI_EX hypercalls if and
only if the local API is emulated/virtualized by KVM, and explicitly reject
said hypercalls if the local APIC is emulated in userspace, i.e. don&amp;#39;t rely
on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.&lt;/p&gt;
&lt;p&gt;Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if
Hyper-V enlightenments are exposed to the guest without an in-kernel local
APIC:&lt;/p&gt;
&lt;p&gt;dump_stack+0xbe/0xfd
  __kasan_report.cold+0x34/0x84
  kasan_report+0x3a/0x50
  __apic_accept_irq+0x3a/0x5c0
  kvm_hv_send_ipi.isra.0+0x34e/0x820
  kvm_hv_hypercall+0x8d9/0x9d0
  kvm_emulate_hypercall+0x506/0x7e0
  __vmx_handle_exit+0x283/0xb60
  vmx_handle_exit+0x1d/0xd0
  vcpu_enter_guest+0x16b0/0x24c0
  vcpu_run+0xc0/0x550
  kvm_arch_vcpu_ioctl_run+0x170/0x6d0
  kvm_vcpu_ioctl+0x413/0xb20
  __se_sys_ioctl+0x111/0x160
  do_syscal1_64+0x30/0x40
  entry_SYSCALL_64_after_hwframe+0x67/0xd1&lt;/p&gt;
&lt;p&gt;Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode
can&amp;#39;t be modified after vCPUs are created, i.e. if one vCPU has an
in-kernel local APIC, then all vCPUs have an in-kernel local APIC.&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: x86: Reject Hyper-V&amp;#39;s SEND_IPI hypercalls if local APIC isn&amp;#39;t in-kernel&lt;/p&gt;
&lt;p&gt;Advertise support for Hyper-V&amp;#39;s SEND_IPI and SEND_IPI_EX hypercalls if and
only if the local API is emulated/virtualized by KVM, and explicitly reject
said hypercalls if the local APIC is emulated in userspace, i.e. don&amp;#39;t rely
on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.&lt;/p&gt;
&lt;p&gt;Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if
Hyper-V enlightenments are exposed to the guest without an in-kernel local
APIC:&lt;/p&gt;
&lt;p&gt;dump_stack+0xbe/0xfd
  __kasan_report.cold+0x34/0x84
  kasan_report+0x3a/0x50
  __apic_accept_irq+0x3a/0x5c0
  kvm_hv_send_ipi.isra.0+0x34e/0x820
  kvm_hv_hypercall+0x8d9/0x9d0
  kvm_emulate_hypercall+0x506/0x7e0
  __vmx_handle_exit+0x283/0xb60
  vmx_handle_exit+0x1d/0xd0
  vcpu_enter_guest+0x16b0/0x24c0
  vcpu_run+0xc0/0x550
  kvm_arch_vcpu_ioctl_run+0x170/0x6d0
  kvm_vcpu_ioctl+0x413/0xb20
  __se_sys_ioctl+0x111/0x160
  do_syscal1_64+0x30/0x40
  entry_SYSCALL_64_after_hwframe+0x67/0xd1&lt;/p&gt;
&lt;p&gt;Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode
can&amp;#39;t be modified after vCPUs are created, i.e. if one vCPU has an
in-kernel local APIC, then all vCPUs have an in-kernel local APIC.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-21779</guid>
    </item>
    <item>
      <title>GHSA-mmj4-6ppp-mqr2</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-mmj4-6ppp-mqr2</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: x86: Reject Hyper-V&amp;#39;s SEND_IPI hypercalls if local APIC isn&amp;#39;t in-kernel&lt;/p&gt;
&lt;p&gt;Advertise support for Hyper-V&amp;#39;s SEND_IPI and SEND_IPI_EX hypercalls if and
only if the local API is emulated/virtualized by KVM, and explicitly reject
said hypercalls if the local APIC is emulated in userspace, i.e. don&amp;#39;t rely
on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.&lt;/p&gt;
&lt;p&gt;Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if
Hyper-V enlightenments are exposed to the guest without an in-kernel local
APIC:&lt;/p&gt;
&lt;p&gt;dump_stack+0xbe/0xfd
  __kasan_report.cold+0x34/0x84
  kasan_report+0x3a/0x50
  __apic_accept_irq+0x3a/0x5c0
  kvm_hv_send_ipi.isra.0+0x34e/0x820
  kvm_hv_hypercall+0x8d9/0x9d0
  kvm_emulate_hypercall+0x506/0x7e0
  __vmx_handle_exit+0x283/0xb60
  vmx_handle_exit+0x1d/0xd0
  vcpu_enter_guest+0x16b0/0x24c0
  vcpu_run+0xc0/0x550
  kvm_arch_vcpu_ioctl_run+0x170/0x6d0
  kvm_vcpu_ioctl+0x413/0xb20
  __se_sys_ioctl+0x111/0x160
  do_syscal1_64+0x30/0x40
  entry_SYSCALL_64_after_hwframe+0x67/0xd1&lt;/p&gt;
&lt;p&gt;Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode
can&amp;#39;t be modified after vCPUs are created, i.e. if one vCPU has an
in-kernel local APIC, then all vCPUs have an in-kernel local APIC.&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: x86: Reject Hyper-V&amp;#39;s SEND_IPI hypercalls if local APIC isn&amp;#39;t in-kernel&lt;/p&gt;
&lt;p&gt;Advertise support for Hyper-V&amp;#39;s SEND_IPI and SEND_IPI_EX hypercalls if and
only if the local API is emulated/virtualized by KVM, and explicitly reject
said hypercalls if the local APIC is emulated in userspace, i.e. don&amp;#39;t rely
on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.&lt;/p&gt;
&lt;p&gt;Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if
Hyper-V enlightenments are exposed to the guest without an in-kernel local
APIC:&lt;/p&gt;
&lt;p&gt;dump_stack+0xbe/0xfd
  __kasan_report.cold+0x34/0x84
  kasan_report+0x3a/0x50
  __apic_accept_irq+0x3a/0x5c0
  kvm_hv_send_ipi.isra.0+0x34e/0x820
  kvm_hv_hypercall+0x8d9/0x9d0
  kvm_emulate_hypercall+0x506/0x7e0
  __vmx_handle_exit+0x283/0xb60
  vmx_handle_exit+0x1d/0xd0
  vcpu_enter_guest+0x16b0/0x24c0
  vcpu_run+0xc0/0x550
  kvm_arch_vcpu_ioctl_run+0x170/0x6d0
  kvm_vcpu_ioctl+0x413/0xb20
  __se_sys_ioctl+0x111/0x160
  do_syscal1_64+0x30/0x40
  entry_SYSCALL_64_after_hwframe+0x67/0xd1&lt;/p&gt;
&lt;p&gt;Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode
can&amp;#39;t be modified after vCPUs are created, i.e. if one vCPU has an
in-kernel local APIC, then all vCPUs have an in-kernel local APIC.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-mmj4-6ppp-mqr2</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-21779 — KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-21779</link>
      <description>msrc_CVE-2025-21779</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-21779</guid>
    </item>
    <item>
      <title>OESA-2025-1283 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-1283</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: sfc: add missing xdp queue reinitialization&lt;/p&gt;
&lt;p&gt;After rx/tx ring buffer size is changed, kernel panic occurs when
it acts XDP_TX or XDP_REDIRECT.&lt;/p&gt;
&lt;p&gt;When tx/rx ring buffer size is changed(ethtool -G), sfc driver
reallocates and reinitializes rx and tx queues and their buffer
(tx_queue-&amp;amp;gt;buffer).
But it misses reinitializing xdp queues(efx-&amp;amp;gt;xdp_tx_queues).
So, while it is acting XDP_TX or XDP_REDIRECT, it uses the uninitialized
tx_queue-&amp;amp;gt;buffer.&lt;/p&gt;
&lt;p&gt;A new function efx_set_xdp_channels() is separated from efx_set_channels()
to handle only xdp queues.&lt;/p&gt;
&lt;p&gt;Splat looks like:
   BUG: kernel NULL pointer dereference, address: 000000000000002a
   #PF: supervisor write access in kernel mode
   #PF: error_code(0x0002) - not-present page
   PGD 0 P4D 0
   Oops: 0002 [#4] PREEMPT SMP NOPTI
   RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc]
   CPU: 2 PID: 0 Comm: swapper/2 Tainted: G      D           5.17.0+ #55 e8beeee8289528f11357029357cf
   Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80
   RSP: 0018:ffff92f121e45c60 EFLAGS: 00010297
   RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc]
   RAX: 0000000000000040 RBX: ffff92ea506895c0 RCX: ffffffffc0330870
   RDX: 0000000000000001 RSI: 00000001139b10ce RDI: ffff92ea506895c0
   RBP: ffffffffc0358a80 R08: 00000001139b110d R09: 0000000000000000
   R10: 0000000…&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: sfc: add missing xdp queue reinitialization&lt;/p&gt;
&lt;p&gt;After rx/tx ring buffer size is changed, kernel panic occurs when
it acts XDP_TX or XDP_REDIRECT.&lt;/p&gt;
&lt;p&gt;When tx/rx ring buffer size is changed(ethtool -G), sfc driver
reallocates and reinitializes rx and tx queues and their buffer
(tx_queue-&amp;amp;gt;buffer).
But it misses reinitializing xdp queues(efx-&amp;amp;gt;xdp_tx_queues).
So, while it is acting XDP_TX or XDP_REDIRECT, it uses the uninitialized
tx_queue-&amp;amp;gt;buffer.&lt;/p&gt;
&lt;p&gt;A new function efx_set_xdp_channels() is separated from efx_set_channels()
to handle only xdp queues.&lt;/p&gt;
&lt;p&gt;Splat looks like:
   BUG: kernel NULL pointer dereference, address: 000000000000002a
   #PF: supervisor write access in kernel mode
   #PF: error_code(0x0002) - not-present page
   PGD 0 P4D 0
   Oops: 0002 [#4] PREEMPT SMP NOPTI
   RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc]
   CPU: 2 PID: 0 Comm: swapper/2 Tainted: G      D           5.17.0+ #55 e8beeee8289528f11357029357cf
   Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80
   RSP: 0018:ffff92f121e45c60 EFLAGS: 00010297
   RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc]
   RAX: 0000000000000040 RBX: ffff92ea506895c0 RCX: ffffffffc0330870
   RDX: 0000000000000001 RSI: 00000001139b10ce RDI: ffff92ea506895c0
   RBP: ffffffffc0358a80 R08: 00000001139b110d R09: 0000000000000000
   R10: 0000000…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-1283</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:01600-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:01600-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:01600-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-21779</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-21779</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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 171 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reject Hyper-V&amp;#39;s SEND_IPI hypercalls if local APIC isn&amp;#39;t in-kernel Advertise support for Hyper-V&amp;#39;s SEND_IPI and SEND_IPI_EX hypercalls if and only if the local API is emulated/virtualized by KVM, and explicitly reject said hypercalls if the local APIC is emulated in userspace, i.e. don&amp;#39;t rely on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID. Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if Hyper-V enlightenments are exposed to the guest without an in-kernel local APIC:   dump_stack+0xbe/0xfd   __kasan_report.cold+0x34/0x84   kasan_report+0x3a/0x50   __apic_accept_irq+0x3a/0x5c0   kvm_hv_send_ipi.isra.0+0x34e/0x820   kvm_hv_hypercall+0x8d9/0x9d0   kvm_emulate_hypercall+0x506/0x7e0   __vmx_handle_exit+0x283/0xb60   vmx_handle_exit+0x1d/0xd0   vcpu_enter_guest+0x16b0/0x24c0   vcpu_run+0xc0/0x550   kvm_arch_vcpu_ioctl_run+0x170/0x6d0   kvm_vcpu_ioctl+0x413/0xb20   __se_sys_ioctl+0x111/0x160   do_syscal1_64+0x30/0x40   entry_SYSCALL_64_after_hwframe+0x67/0xd1 Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode can&amp;#39;t be modified after vCPUs are created, i.e. if one vCPU has an in-kernel local APIC, then all vCPUs have an in-kernel local APIC.&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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 171 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reject Hyper-V&amp;#39;s SEND_IPI hypercalls if local APIC isn&amp;#39;t in-kernel Advertise support for Hyper-V&amp;#39;s SEND_IPI and SEND_IPI_EX hypercalls if and only if the local API is emulated/virtualized by KVM, and explicitly reject said hypercalls if the local APIC is emulated in userspace, i.e. don&amp;#39;t rely on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID. Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if Hyper-V enlightenments are exposed to the guest without an in-kernel local APIC:   dump_stack+0xbe/0xfd   __kasan_report.cold+0x34/0x84   kasan_report+0x3a/0x50   __apic_accept_irq+0x3a/0x5c0   kvm_hv_send_ipi.isra.0+0x34e/0x820   kvm_hv_hypercall+0x8d9/0x9d0   kvm_emulate_hypercall+0x506/0x7e0   __vmx_handle_exit+0x283/0xb60   vmx_handle_exit+0x1d/0xd0   vcpu_enter_guest+0x16b0/0x24c0   vcpu_run+0xc0/0x550   kvm_arch_vcpu_ioctl_run+0x170/0x6d0   kvm_vcpu_ioctl+0x413/0xb20   __se_sys_ioctl+0x111/0x160   do_syscal1_64+0x30/0x40   entry_SYSCALL_64_after_hwframe+0x67/0xd1 Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode can&amp;#39;t be modified after vCPUs are created, i.e. if one vCPU has an in-kernel local APIC, then all vCPUs have an in-kernel local APIC.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-21779</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-0453 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0453</link>
      <description>&lt;p&gt;Ein entfernter Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen um die Vertraulichkeit, Integrität und Verfügbarkeit zu gefährden.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein entfernter Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen um die Vertraulichkeit, Integrität und Verfügbarkeit zu gefährden.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0453</guid>
    </item>
  </channel>
</rss>
