https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 21 Oct 2026 12:52:39 +0000 https://cve.radiocsirt.org/vuln/cve-2021-46978 <p><strong>Affected:</strong> Linux, linux_kernel</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: nVMX: Always make an attempt to map eVMCS after migration</p> <p>When enlightened VMCS is in use and nested state is migrated with vmx_get_nested_state()/vmx_set_nested_state() KVM can&#39;t map evmcs page right away: evmcs gpa is not &#39;struct kvm_vmx_nested_state_hdr&#39; and we can&#39;t read it from VP assist page because userspace may decide to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state (and QEMU, for example, does exactly that). To make sure eVMCS is mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES request.</p> <p>Commit f2c7ef3ba955 (&#34;KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES on nested vmexit&#34;) added KVM_REQ_GET_NESTED_STATE_PAGES clearing to nested_vmx_vmexit() to make sure MSR permission bitmap is not switched when an immediate exit from L2 to L1 happens right after migration (caused by a pending event, for example). Unfortunately, in the exact same situation we still need to have eVMCS mapped so nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS.</p> <p>As a band-aid, restore nested_get_evmcs_page() when clearing KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The &#39;fix&#39; is far from being ideal as we can&#39;t easily propagate possible failures and even if we could, this is most likely already too late to do so. The whole &#39;KVM_REQ_GET_NESTED_STATE_PAGES&#39; idea for mapping eVMCS after migration seems to be fragile as we diverge too much from the &#39;native&#39; path wh…</p> <p><strong>Affected:</strong> Linux, linux_kernel</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: nVMX: Always make an attempt to map eVMCS after migration</p> <p>When enlightened VMCS is in use and nested state is migrated with vmx_get_nested_state()/vmx_set_nested_state() KVM can&#39;t map evmcs page right away: evmcs gpa is not &#39;struct kvm_vmx_nested_state_hdr&#39; and we can&#39;t read it from VP assist page because userspace may decide to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state (and QEMU, for example, does exactly that). To make sure eVMCS is mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES request.</p> <p>Commit f2c7ef3ba955 (&#34;KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES on nested vmexit&#34;) added KVM_REQ_GET_NESTED_STATE_PAGES clearing to nested_vmx_vmexit() to make sure MSR permission bitmap is not switched when an immediate exit from L2 to L1 happens right after migration (caused by a pending event, for example). Unfortunately, in the exact same situation we still need to have eVMCS mapped so nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS.</p> <p>As a band-aid, restore nested_get_evmcs_page() when clearing KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The &#39;fix&#39; is far from being ideal as we can&#39;t easily propagate possible failures and even if we could, this is most likely already too late to do so. The whole &#39;KVM_REQ_GET_NESTED_STATE_PAGES&#39; idea for mapping eVMCS after migration seems to be fragile as we diverge too much from the &#39;native&#39; path wh…</p> https://cve.radiocsirt.org/vuln/cve-2021-46978