Date: Wed, 28 Feb 2024 23:09:50 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: cve@...nel.org, linux-kernel@...r.kernel.org,
 KVM list <kvm@...r.kernel.org>, Vitaly Kuznetsov <vkuznets@...hat.com>
Cc: gregkh@...nel.org
Subject: Re: CVE-2021-46978: KVM: nVMX: Always make an attempt to map eVMCS
 after migration

On 2/28/24 09:14, Greg Kroah-Hartman wrote:
> From: gregkh@...nel.org
> 
> Description
> ===========
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> KVM: nVMX: Always make an attempt to map eVMCS after migration

How does this break the confidentiality, integrity or availability of 
the host kernel?  It's a fix for a failure to restart the guest after 
migration.  Vitaly can confirm.

Apparently the authority to "dispute or modify an assigned CVE lies 
solely with the maintainers", but we don't have the authority to tell 
you in advance that a CVE is crap, so please consider this vulnerability 
to be disputed.

Unlike what we discussed last week:

- the KVM list is not CC'd so whoever sees this reply will have to find 
the original message on their own

- there is no list gathering all the discussions/complaints about these 
CVEs, since I cannot reply to linux-cve-announce@...r.kernel.org.

This is not the way to run this, and you're not getting more complaints 
just because people don't care, not because it's all fine.

Paolo

[1] 
https://lore.kernel.org/linux-cve-announce/2024022259-CVE-2024-26592-58f7@gregkh/T/#u

> When enlightened VMCS is in use and nested state is migrated with
> vmx_get_nested_state()/vmx_set_nested_state() KVM can't map evmcs
> page right away: evmcs gpa is not 'struct kvm_vmx_nested_state_hdr'
> and we can'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.
> 
> Commit f2c7ef3ba955 ("KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES
> on nested vmexit") 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.
> 
> As a band-aid, restore nested_get_evmcs_page() when clearing
> KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The 'fix' is far
> from being ideal as we can't easily propagate possible failures and even if
> we could, this is most likely already too late to do so. The whole
> 'KVM_REQ_GET_NESTED_STATE_PAGES' idea for mapping eVMCS after migration
> seems to be fragile as we diverge too much from the 'native' path when
> vmptr loading happens on vmx_set_nested_state().
> 
> The Linux kernel CVE team has assigned CVE-2021-46978 to this issue.
> 
> 
> Affected and fixed versions
> ===========================
> 
> 	Issue introduced in 5.10.13 with commit 0faceb7d6dda and fixed in 5.10.38 with commit c8bf64e3fb77
> 	Issue introduced in 5.11 with commit f2c7ef3ba955 and fixed in 5.11.22 with commit 200a45649ab7
> 	Issue introduced in 5.11 with commit f2c7ef3ba955 and fixed in 5.12.5 with commit bd0e8455b85b
> 	Issue introduced in 5.11 with commit f2c7ef3ba955 and fixed in 5.13 with commit f5c7e8425f18
> 
> Please see https://www.kernel.org or a full list of currently supported
> kernel versions by the kernel community.
> 
> Unaffected versions might change over time as fixes are backported to
> older supported kernel versions.  The official CVE entry at
> 	https://cve.org/CVERecord/?id=CVE-2021-46978
> will be updated if fixes are backported, please check that for the most
> up to date information about this issue.
> 
> 
> Affected files
> ==============
> 
> The file(s) affected by this issue are:
> 	arch/x86/kvm/vmx/nested.c
> 
> 
> Mitigation
> ==========
> 
> The Linux kernel CVE team recommends that you update to the latest
> stable kernel version for this, and many other bugfixes.  Individual
> changes are never tested alone, but rather are part of a larger kernel
> release.  Cherry-picking individual commits is not recommended or
> supported by the Linux kernel community at all.  If however, updating to
> the latest release is impossible, the individual changes to resolve this
> issue can be found at these commits:
> 	https://git.kernel.org/stable/c/c8bf64e3fb77cc19bad146fbe26651985b117194
> 	https://git.kernel.org/stable/c/200a45649ab7361bc80c70aebf7165b64f9a6c9f
> 	https://git.kernel.org/stable/c/bd0e8455b85b651a4c77de9616e307129b15aaa7
> 	https://git.kernel.org/stable/c/f5c7e8425f18fdb9bdb7d13340651d7876890329
> 

Powered by blists - more mailing lists