Bug 195167

Summary: INVEPT might crash the host
Product: Virtualization Reporter: minoura makoto (minoura)
Component: kvmAssignee: virtualization_kvm
Status: NEW ---    
Severity: normal CC: code
Priority: P1    
Hardware: x86-64   
OS: Linux   
Kernel Version: 3.11 - 3.14 Tree: Mainline
Regression: No
Attachments: build and insmod'ing the module on a guest linux crashes the host

Description minoura makoto 2017-03-31 02:30:17 UTC
Created attachment 255653 [details]
build and insmod'ing the module on a guest linux crashes the host

KVM in linux 3.11 - 3.14 (including long term supported 3.12.72) has a
flaw in INVEPT emulation that could crash the host.

[ 1046.384746] BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
[ 1046.387386] IP: [<ffffffffa05b3ca3>] handle_invept+0x123/0x170 [kvm_intel]
[ 1046.389577] PGD 0 
[ 1046.390273] Oops: 0000 [#1] SMP 

(tested with Ubuntu 14.04 linux-image-3.13.0-113-generic)

The host KVM touches NULL pointer (vmx->nested.current_vmcs12) when a
(crafted or buggy) guest issues a single-context INVEPT instruction
*without* VMPTRLD like this:

	kvm_cpu_vmxon(phys_addr);
	ept_sync_context(0);

(requires nested EPT; full PoC module code attached)

This flaw was introduced in commit bfd0a56b90005f8c8a004baf407ad90045c2b11e
(nEPT: Nested INVEPT) and removed in 4b855078601fc422dbac3059f2215e776f49780f
(KVM: nVMX: Don't advertise single context invalidation for invept).
Therefore there should be two ways to fix this.

a. pullup bfd0a56b90005f (and 45e11817d5703e)
b. check current_vmcs12 before accessing for minimal fix:

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index d9e567f..d785e9c 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -6391,6 +6391,8 @@ static int handle_invept(struct kvm_vcpu *vcpu)
 
 	switch (type) {
 	case VMX_EPT_EXTENT_CONTEXT:
+		if (to_vmx(vcpu)->nested.current_vmptr == -1ull)
+			break;
 		if ((operand.eptp & eptp_mask) !=
 				(nested_ept_get_cr3(vcpu) & eptp_mask))
 			break;
Comment 1 Tyler Hicks 2017-04-24 20:45:17 UTC
I've requested a CVE for this issue via https://cveform.mitre.org/
Comment 2 Tyler Hicks 2017-04-24 22:12:53 UTC
MITRE has assigned CVE-2017-8106 to this issue.