Linux Kernel up to 5.10.37/5.11.21/5.12.4 nVMX vmx_get_nested_state/vmx_set_nested_state permission

Summaryinfo

A vulnerability identified as critical has been detected in Linux Kernel up to 5.10.37/5.11.21/5.12.4. The affected element is the function vmx_get_nested_state/vmx_set_nested_state of the component nVMX. This manipulation causes permission. The identification of this vulnerability is CVE-2021-46978. There is no exploit available. You should upgrade the affected component.

Detailsinfo

A vulnerability has been found in Linux Kernel up to 5.10.37/5.11.21/5.12.4 (Operating System) and classified as critical. Affected by this vulnerability is the function vmx_get_nested_state/vmx_set_nested_state of the component nVMX. The manipulation with an unknown input leads to a permission vulnerability. The CWE definition for the vulnerability is CWE-275. As an impact it is known to affect confidentiality, integrity, and availability. The summary by CVE is:

In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Always make an attempt to map eVMCS after migration 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 weakness was shared 02/28/2024. It is possible to read the advisory at git.kernel.org. This vulnerability is known as CVE-2021-46978 since 02/27/2024. Technical details of the vulnerability are known, but there is no available exploit. The attack technique deployed by this issue is T1222 according to MITRE ATT&CK.

Upgrading to version 5.10.38, 5.11.22, 5.12.5 or 5.13 eliminates this vulnerability. Applying the patch c8bf64e3fb77/200a45649ab7/bd0e8455b85b/f5c7e8425f18 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 5.10.0
• 5.10.1
• 5.10.2
• 5.10.3
• 5.10.4
• 5.10.5
• 5.10.6
• 5.10.7
• 5.10.8
• 5.10.9
• 5.10.10
• 5.10.11
• 5.10.12
• 5.10.13
• 5.10.14
• 5.10.15
• 5.10.16
• 5.10.17
• 5.10.18
• 5.10.19
• 5.10.20
• 5.10.21
• 5.10.22
• 5.10.23
• 5.10.24
• 5.10.25
• 5.10.26
• 5.10.27
• 5.10.28
• 5.10.29
• 5.10.30
• 5.10.31
• 5.10.32
• 5.10.33
• 5.10.34
• 5.10.35
• 5.10.36
• 5.10.37
• 5.11.0
• 5.11.1
• 5.11.2
• 5.11.3
• 5.11.4
• 5.11.5
• 5.11.6
• 5.11.7
• 5.11.8
• 5.11.9
• 5.11.10
• 5.11.11
• 5.11.12
• 5.11.13
• 5.11.14
• 5.11.15
• 5.11.16
• 5.11.17
• 5.11.18
• 5.11.19
• 5.11.20
• 5.11.21
• 5.12.0
• 5.12.1
• 5.12.2
• 5.12.3
• 5.12.4

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion