CVE-2021-46978

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: nVMX: Always make an attempt to map eVMCS after migration<br /> <br /> When enlightened VMCS is in use and nested state is migrated with<br /> vmx_get_nested_state()/vmx_set_nested_state() KVM can&amp;#39;t map evmcs<br /> page right away: evmcs gpa is not &amp;#39;struct kvm_vmx_nested_state_hdr&amp;#39;<br /> and we can&amp;#39;t read it from VP assist page because userspace may decide<br /> to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state<br /> (and QEMU, for example, does exactly that). To make sure eVMCS is<br /> mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES<br /> request.<br /> <br /> Commit f2c7ef3ba955 ("KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES<br /> on nested vmexit") added KVM_REQ_GET_NESTED_STATE_PAGES clearing to<br /> nested_vmx_vmexit() to make sure MSR permission bitmap is not switched<br /> when an immediate exit from L2 to L1 happens right after migration (caused<br /> by a pending event, for example). Unfortunately, in the exact same<br /> situation we still need to have eVMCS mapped so<br /> nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS.<br /> <br /> As a band-aid, restore nested_get_evmcs_page() when clearing<br /> KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The &amp;#39;fix&amp;#39; is far<br /> from being ideal as we can&amp;#39;t easily propagate possible failures and even if<br /> we could, this is most likely already too late to do so. The whole<br /> &amp;#39;KVM_REQ_GET_NESTED_STATE_PAGES&amp;#39; idea for mapping eVMCS after migration<br /> seems to be fragile as we diverge too much from the &amp;#39;native&amp;#39; path when<br /> vmptr loading happens on vmx_set_nested_state().