<?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>Tue, 06 Oct 2026 13:24:56 +0000</lastBuildDate>
    <item>
      <title>CVE-2021-47092 — KVM: VMX: Always clear vmx-&gt;fail on emulation_required</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2021-47092</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: VMX: Always clear vmx-&amp;gt;fail on emulation_required&lt;/p&gt;
&lt;p&gt;Revert a relatively recent change that set vmx-&amp;gt;fail if the vCPU is in L2
and emulation_required is true, as that behavior is completely bogus.
Setting vmx-&amp;gt;fail and synthesizing a VM-Exit is contradictory and wrong:&lt;/p&gt;
&lt;p&gt;(a) it&amp;#39;s impossible to have both a VM-Fail and VM-Exit
  (b) vmcs.EXIT_REASON is not modified on VM-Fail
  (c) emulation_required refers to guest state and guest state checks are
      always VM-Exits, not VM-Fails.&lt;/p&gt;
&lt;p&gt;For KVM specifically, emulation_required is handled before nested exits
in __vmx_handle_exit(), thus setting vmx-&amp;gt;fail has no immediate effect,
i.e. KVM calls into handle_invalid_guest_state() and vmx-&amp;gt;fail is ignored.
Setting vmx-&amp;gt;fail can ultimately result in a WARN in nested_vmx_vmexit()
firing when tearing down the VM as KVM never expects vmx-&amp;gt;fail to be set
when L2 is active, KVM always reflects those errors into L1.&lt;/p&gt;
&lt;p&gt;------------[ cut here ]------------
  WARNING: CPU: 0 PID: 21158 at arch/x86/kvm/vmx/nested.c:4548
                                nested_vmx_vmexit+0x16bd/0x17e0
                                arch/x86/kvm/vmx/nested.c:4547
  Modules linked in:
  CPU: 0 PID: 21158 Comm: syz-executor.1 Not tainted 5.16.0-rc3-syzkaller #0
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
  RIP: 0010:nested_vmx_vmexit+0x16bd/0x17e0 arch/x86/kvm/vmx/nested.c:4547
  Code: &amp;lt;0f&amp;gt; 0b…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: VMX: Always clear vmx-&amp;gt;fail on emulation_required&lt;/p&gt;
&lt;p&gt;Revert a relatively recent change that set vmx-&amp;gt;fail if the vCPU is in L2
and emulation_required is true, as that behavior is completely bogus.
Setting vmx-&amp;gt;fail and synthesizing a VM-Exit is contradictory and wrong:&lt;/p&gt;
&lt;p&gt;(a) it&amp;#39;s impossible to have both a VM-Fail and VM-Exit
  (b) vmcs.EXIT_REASON is not modified on VM-Fail
  (c) emulation_required refers to guest state and guest state checks are
      always VM-Exits, not VM-Fails.&lt;/p&gt;
&lt;p&gt;For KVM specifically, emulation_required is handled before nested exits
in __vmx_handle_exit(), thus setting vmx-&amp;gt;fail has no immediate effect,
i.e. KVM calls into handle_invalid_guest_state() and vmx-&amp;gt;fail is ignored.
Setting vmx-&amp;gt;fail can ultimately result in a WARN in nested_vmx_vmexit()
firing when tearing down the VM as KVM never expects vmx-&amp;gt;fail to be set
when L2 is active, KVM always reflects those errors into L1.&lt;/p&gt;
&lt;p&gt;------------[ cut here ]------------
  WARNING: CPU: 0 PID: 21158 at arch/x86/kvm/vmx/nested.c:4548
                                nested_vmx_vmexit+0x16bd/0x17e0
                                arch/x86/kvm/vmx/nested.c:4547
  Modules linked in:
  CPU: 0 PID: 21158 Comm: syz-executor.1 Not tainted 5.16.0-rc3-syzkaller #0
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
  RIP: 0010:nested_vmx_vmexit+0x16bd/0x17e0 arch/x86/kvm/vmx/nested.c:4547
  Code: &amp;lt;0f&amp;gt; 0b…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2021-47092</guid>
    </item>
  </channel>
</rss>
