]> git.baikalelectronics.ru Git - kernel.git/commit
KVM: x86: nVMX: close leak of L0's x2APIC MSRs (CVE-2019-3887)
authorMarc Orr <marcorr@google.com>
Tue, 2 Apr 2019 06:55:59 +0000 (23:55 -0700)
committerPaolo Bonzini <pbonzini@redhat.com>
Fri, 5 Apr 2019 19:08:22 +0000 (21:08 +0200)
commitd3ff22aaf012951bec2092d7141127bbd515082a
tree2db0134eb76c0857b4bd58b356814edd100eb581
parentfed45cfdbd7e1364ba718bac50a11a753e40e8af
KVM: x86: nVMX: close leak of L0's x2APIC MSRs (CVE-2019-3887)

The nested_vmx_prepare_msr_bitmap() function doesn't directly guard the
x2APIC MSR intercepts with the "virtualize x2APIC mode" MSR. As a
result, we discovered the potential for a buggy or malicious L1 to get
access to L0's x2APIC MSRs, via an L2, as follows.

1. L1 executes WRMSR(IA32_SPEC_CTRL, 1). This causes the spec_ctrl
variable, in nested_vmx_prepare_msr_bitmap() to become true.
2. L1 disables "virtualize x2APIC mode" in VMCS12.
3. L1 enables "APIC-register virtualization" in VMCS12.

Now, KVM will set VMCS02's x2APIC MSR intercepts from VMCS12, and then
set "virtualize x2APIC mode" to 0 in VMCS02. Oops.

This patch closes the leak by explicitly guarding VMCS02's x2APIC MSR
intercepts with VMCS12's "virtualize x2APIC mode" control.

The scenario outlined above and fix prescribed here, were verified with
a related patch in kvm-unit-tests titled "Add leak scenario to
virt_x2apic_mode_test".

Note, it looks like this issue may have been introduced inadvertently
during a merge---see 8aa7c77dee58.

Signed-off-by: Marc Orr <marcorr@google.com>
Reviewed-by: Jim Mattson <jmattson@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
arch/x86/kvm/vmx/nested.c