<?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 04:58:22 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-07344</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-07344</link>
      <description>bdu:2025-07344</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-07344</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0496 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0496</link>
      <description>certfr-2024-avi-0496</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0496</guid>
    </item>
    <item>
      <title>EUVD-2026-309606</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-309606</link>
      <description>EUVD-2026-309606</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-309606</guid>
    </item>
    <item>
      <title>fkie_cve-2021-47230</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2021-47230</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: x86: Immediately reset the MMU context when the SMM flag is cleared&lt;/p&gt;
&lt;p&gt;Immediately reset the MMU context when the vCPU&amp;#39;s SMM flag is cleared so
that the SMM flag in the MMU role is always synchronized with the vCPU&amp;#39;s
flag.  If RSM fails (which isn&amp;#39;t correctly emulated), KVM will bail
without calling post_leave_smm() and leave the MMU in a bad state.&lt;/p&gt;
&lt;p&gt;The bad MMU role can lead to a NULL pointer dereference when grabbing a
shadow page&amp;#39;s rmap for a page fault as the initial lookups for the gfn
will happen with the vCPU&amp;#39;s SMM flag (=0), whereas the rmap lookup will
use the shadow page&amp;#39;s SMM flag, which comes from the MMU (=1).  SMM has
an entirely different set of memslots, and so the initial lookup can find
a memslot (SMM=0) and then explode on the rmap memslot lookup (SMM=1).&lt;/p&gt;
&lt;p&gt;general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
  KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
  CPU: 1 PID: 8410 Comm: syz-executor382 Not tainted 5.13.0-rc5-syzkaller #0
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
  RIP: 0010:__gfn_to_rmap arch/x86/kvm/mmu/mmu.c:935 [inline]
  RIP: 0010:gfn_to_rmap+0x2b0/0x4d0 arch/x86/kvm/mmu/mmu.c:947
  Code: &amp;lt;42&amp;gt; 80 3c 20 00 74 08 4c 89 ff e8 f1 79 a9 00 4c 89 fb 4d 8b 37 44
  RSP: 0018:ffffc90000ffef98 EFLAGS: 00010246
  RAX: 0000000000000000 RBX: ffff888015b9…&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: Immediately reset the MMU context when the SMM flag is cleared&lt;/p&gt;
&lt;p&gt;Immediately reset the MMU context when the vCPU&amp;#39;s SMM flag is cleared so
that the SMM flag in the MMU role is always synchronized with the vCPU&amp;#39;s
flag.  If RSM fails (which isn&amp;#39;t correctly emulated), KVM will bail
without calling post_leave_smm() and leave the MMU in a bad state.&lt;/p&gt;
&lt;p&gt;The bad MMU role can lead to a NULL pointer dereference when grabbing a
shadow page&amp;#39;s rmap for a page fault as the initial lookups for the gfn
will happen with the vCPU&amp;#39;s SMM flag (=0), whereas the rmap lookup will
use the shadow page&amp;#39;s SMM flag, which comes from the MMU (=1).  SMM has
an entirely different set of memslots, and so the initial lookup can find
a memslot (SMM=0) and then explode on the rmap memslot lookup (SMM=1).&lt;/p&gt;
&lt;p&gt;general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
  KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
  CPU: 1 PID: 8410 Comm: syz-executor382 Not tainted 5.13.0-rc5-syzkaller #0
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
  RIP: 0010:__gfn_to_rmap arch/x86/kvm/mmu/mmu.c:935 [inline]
  RIP: 0010:gfn_to_rmap+0x2b0/0x4d0 arch/x86/kvm/mmu/mmu.c:947
  Code: &amp;lt;42&amp;gt; 80 3c 20 00 74 08 4c 89 ff e8 f1 79 a9 00 4c 89 fb 4d 8b 37 44
  RSP: 0018:ffffc90000ffef98 EFLAGS: 00010246
  RAX: 0000000000000000 RBX: ffff888015b9…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2021-47230</guid>
    </item>
    <item>
      <title>GHSA-j8hx-6rxw-p4r9</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-j8hx-6rxw-p4r9</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: x86: Immediately reset the MMU context when the SMM flag is cleared&lt;/p&gt;
&lt;p&gt;Immediately reset the MMU context when the vCPU&amp;#39;s SMM flag is cleared so
that the SMM flag in the MMU role is always synchronized with the vCPU&amp;#39;s
flag.  If RSM fails (which isn&amp;#39;t correctly emulated), KVM will bail
without calling post_leave_smm() and leave the MMU in a bad state.&lt;/p&gt;
&lt;p&gt;The bad MMU role can lead to a NULL pointer dereference when grabbing a
shadow page&amp;#39;s rmap for a page fault as the initial lookups for the gfn
will happen with the vCPU&amp;#39;s SMM flag (=0), whereas the rmap lookup will
use the shadow page&amp;#39;s SMM flag, which comes from the MMU (=1).  SMM has
an entirely different set of memslots, and so the initial lookup can find
a memslot (SMM=0) and then explode on the rmap memslot lookup (SMM=1).&lt;/p&gt;
&lt;p&gt;general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
  KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
  CPU: 1 PID: 8410 Comm: syz-executor382 Not tainted 5.13.0-rc5-syzkaller #0
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
  RIP: 0010:__gfn_to_rmap arch/x86/kvm/mmu/mmu.c:935 [inline]
  RIP: 0010:gfn_to_rmap+0x2b0/0x4d0 arch/x86/kvm/mmu/mmu.c:947
  Code: &amp;lt;42&amp;gt; 80 3c 20 00 74 08 4c 89 ff e8 f1 79 a9 00 4c 89 fb 4d 8b 37 44
  RSP: 0018:ffffc90000ffef98 EFLAGS: 00010246
  RAX: 0000000000000000 RBX: ffff888015b9…&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: Immediately reset the MMU context when the SMM flag is cleared&lt;/p&gt;
&lt;p&gt;Immediately reset the MMU context when the vCPU&amp;#39;s SMM flag is cleared so
that the SMM flag in the MMU role is always synchronized with the vCPU&amp;#39;s
flag.  If RSM fails (which isn&amp;#39;t correctly emulated), KVM will bail
without calling post_leave_smm() and leave the MMU in a bad state.&lt;/p&gt;
&lt;p&gt;The bad MMU role can lead to a NULL pointer dereference when grabbing a
shadow page&amp;#39;s rmap for a page fault as the initial lookups for the gfn
will happen with the vCPU&amp;#39;s SMM flag (=0), whereas the rmap lookup will
use the shadow page&amp;#39;s SMM flag, which comes from the MMU (=1).  SMM has
an entirely different set of memslots, and so the initial lookup can find
a memslot (SMM=0) and then explode on the rmap memslot lookup (SMM=1).&lt;/p&gt;
&lt;p&gt;general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
  KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
  CPU: 1 PID: 8410 Comm: syz-executor382 Not tainted 5.13.0-rc5-syzkaller #0
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
  RIP: 0010:__gfn_to_rmap arch/x86/kvm/mmu/mmu.c:935 [inline]
  RIP: 0010:gfn_to_rmap+0x2b0/0x4d0 arch/x86/kvm/mmu/mmu.c:947
  Code: &amp;lt;42&amp;gt; 80 3c 20 00 74 08 4c 89 ff e8 f1 79 a9 00 4c 89 fb 4d 8b 37 44
  RSP: 0018:ffffc90000ffef98 EFLAGS: 00010246
  RAX: 0000000000000000 RBX: ffff888015b9…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-j8hx-6rxw-p4r9</guid>
    </item>
    <item>
      <title>gsd-2021-47230</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2021-47230</link>
      <description>gsd-2021-47230</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2021-47230</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:2010-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:2010-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:2010-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2021-47230</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47230</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.4, Ubuntu:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-gcp-5.4, Ubuntu:18.04:LTS: linux-hwe-5.4, Ubuntu:18.04:LTS: linux-oracle-5.4, Ubuntu:18.04:LTS: linux-raspi-5.4, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure and 80 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Immediately reset the MMU context when the SMM flag is cleared Immediately reset the MMU context when the vCPU&amp;#39;s SMM flag is cleared so that the SMM flag in the MMU role is always synchronized with the vCPU&amp;#39;s flag.  If RSM fails (which isn&amp;#39;t correctly emulated), KVM will bail without calling post_leave_smm() and leave the MMU in a bad state. The bad MMU role can lead to a NULL pointer dereference when grabbing a shadow page&amp;#39;s rmap for a page fault as the initial lookups for the gfn will happen with the vCPU&amp;#39;s SMM flag (=0), whereas the rmap lookup will use the shadow page&amp;#39;s SMM flag, which comes from the MMU (=1).  SMM has an entirely different set of memslots, and so the initial lookup can find a memslot (SMM=0) and then explode on the rmap memslot lookup (SMM=1).   general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN   KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]   CPU: 1 PID: 8410 Comm: syz-executor382 Not tainted 5.13.0-rc5-syzkaller #0   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011   RIP: 0010:__gfn_to_rmap arch/x86/kvm/mmu/mmu.c:935 [inline]   RIP: 0010:gfn_to_rmap+0x2b0/0x4d0 arch/x86/kvm/mmu/mmu.c:947   Code: &amp;lt;42&amp;gt; 80 3c 20 00 74 08 4c 89 ff e8 f1 79 a9 00 4c 89 fb 4d 8b 37 44   RSP: 0018:ffffc90000ffef98 EFLAGS: 00010246   RAX: 0000000000000000 RBX: ffff888015b9f414…&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.4, Ubuntu:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-gcp-5.4, Ubuntu:18.04:LTS: linux-hwe-5.4, Ubuntu:18.04:LTS: linux-oracle-5.4, Ubuntu:18.04:LTS: linux-raspi-5.4, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure and 80 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Immediately reset the MMU context when the SMM flag is cleared Immediately reset the MMU context when the vCPU&amp;#39;s SMM flag is cleared so that the SMM flag in the MMU role is always synchronized with the vCPU&amp;#39;s flag.  If RSM fails (which isn&amp;#39;t correctly emulated), KVM will bail without calling post_leave_smm() and leave the MMU in a bad state. The bad MMU role can lead to a NULL pointer dereference when grabbing a shadow page&amp;#39;s rmap for a page fault as the initial lookups for the gfn will happen with the vCPU&amp;#39;s SMM flag (=0), whereas the rmap lookup will use the shadow page&amp;#39;s SMM flag, which comes from the MMU (=1).  SMM has an entirely different set of memslots, and so the initial lookup can find a memslot (SMM=0) and then explode on the rmap memslot lookup (SMM=1).   general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN   KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]   CPU: 1 PID: 8410 Comm: syz-executor382 Not tainted 5.13.0-rc5-syzkaller #0   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011   RIP: 0010:__gfn_to_rmap arch/x86/kvm/mmu/mmu.c:935 [inline]   RIP: 0010:gfn_to_rmap+0x2b0/0x4d0 arch/x86/kvm/mmu/mmu.c:947   Code: &amp;lt;42&amp;gt; 80 3c 20 00 74 08 4c 89 ff e8 f1 79 a9 00 4c 89 fb 4d 8b 37 44   RSP: 0018:ffffc90000ffef98 EFLAGS: 00010246   RAX: 0000000000000000 RBX: ffff888015b9f414…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47230</guid>
    </item>
  </channel>
</rss>
