<?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>Wed, 07 Oct 2026 22:05:32 +0000</lastBuildDate>
    <item>
      <title>CVE-2021-47230 — KVM: x86: Immediately reset the MMU context when the SMM flag is cleared</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2021-47230</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux, linux_kernel&lt;/p&gt;
&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;&lt;strong&gt;Affected:&lt;/strong&gt; Linux, linux_kernel&lt;/p&gt;
&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/cve-2021-47230</guid>
    </item>
  </channel>
</rss>
