From: Maxim Levitsky mlevitsk@redhat.com
[ upstream commit 0f923e07124df069ba68d8bb12324398f4b6b709 ]
* Invert the mask of bits that we pick from L2 in nested_vmcb02_prepare_control
* Invert and explicitly use VIRQ related bits bitmask in svm_clear_vintr
This fixes a security issue that allowed a malicious L1 to run L2 with AVIC enabled, which allowed the L2 to exploit the uninitialized and enabled AVIC to read/write the host physical memory at some offsets.
Fixes: 3d6368ef580a ("KVM: SVM: Add VMRUN handler") Signed-off-by: Maxim Levitsky mlevitsk@redhat.com Signed-off-by: Paolo Bonzini pbonzini@redhat.com --- The above upstream SHA1 is still on its way to Linus
arch/x86/include/asm/svm.h | 2 ++ arch/x86/kvm/svm/nested.c | 11 +++++++---- arch/x86/kvm/svm/svm.c | 8 ++++---- 3 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h index 1c561945b426..6278111bbf97 100644 --- a/arch/x86/include/asm/svm.h +++ b/arch/x86/include/asm/svm.h @@ -178,6 +178,8 @@ struct __attribute__ ((__packed__)) vmcb_control_area { #define V_IGN_TPR_SHIFT 20 #define V_IGN_TPR_MASK (1 << V_IGN_TPR_SHIFT)
+#define V_IRQ_INJECTION_BITS_MASK (V_IRQ_MASK | V_INTR_PRIO_MASK | V_IGN_TPR_MASK) + #define V_INTR_MASKING_SHIFT 24 #define V_INTR_MASKING_MASK (1 << V_INTR_MASKING_SHIFT)
diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c index fb204eaa8bb3..4b8635d2296a 100644 --- a/arch/x86/kvm/svm/nested.c +++ b/arch/x86/kvm/svm/nested.c @@ -429,7 +429,10 @@ static void nested_prepare_vmcb_save(struct vcpu_svm *svm, struct vmcb *vmcb12)
static void nested_prepare_vmcb_control(struct vcpu_svm *svm) { - const u32 mask = V_INTR_MASKING_MASK | V_GIF_ENABLE_MASK | V_GIF_MASK; + const u32 int_ctl_vmcb01_bits = + V_INTR_MASKING_MASK | V_GIF_MASK | V_GIF_ENABLE_MASK; + + const u32 int_ctl_vmcb12_bits = V_TPR_MASK | V_IRQ_INJECTION_BITS_MASK;
if (nested_npt_enabled(svm)) nested_svm_init_mmu_context(&svm->vcpu); @@ -437,9 +440,9 @@ static void nested_prepare_vmcb_control(struct vcpu_svm *svm) svm->vmcb->control.tsc_offset = svm->vcpu.arch.tsc_offset = svm->vcpu.arch.l1_tsc_offset + svm->nested.ctl.tsc_offset;
- svm->vmcb->control.int_ctl = - (svm->nested.ctl.int_ctl & ~mask) | - (svm->nested.hsave->control.int_ctl & mask); + svm->vmcb->control.int_ctl = + (svm->nested.ctl.int_ctl & int_ctl_vmcb12_bits) | + (svm->nested.hsave->control.int_ctl & int_ctl_vmcb01_bits);
svm->vmcb->control.virt_ext = svm->nested.ctl.virt_ext; svm->vmcb->control.int_vector = svm->nested.ctl.int_vector; diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index f262edf7551b..4236188dda7d 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -1560,17 +1560,17 @@ static void svm_set_vintr(struct vcpu_svm *svm)
static void svm_clear_vintr(struct vcpu_svm *svm) { - const u32 mask = V_TPR_MASK | V_GIF_ENABLE_MASK | V_GIF_MASK | V_INTR_MASKING_MASK; svm_clr_intercept(svm, INTERCEPT_VINTR);
/* Drop int_ctl fields related to VINTR injection. */ - svm->vmcb->control.int_ctl &= mask; + svm->vmcb->control.int_ctl &= ~V_IRQ_INJECTION_BITS_MASK; if (is_guest_mode(&svm->vcpu)) { - svm->nested.hsave->control.int_ctl &= mask; + svm->nested.hsave->control.int_ctl &= ~V_IRQ_INJECTION_BITS_MASK;
WARN_ON((svm->vmcb->control.int_ctl & V_TPR_MASK) != (svm->nested.ctl.int_ctl & V_TPR_MASK)); - svm->vmcb->control.int_ctl |= svm->nested.ctl.int_ctl & ~mask; + svm->vmcb->control.int_ctl |= svm->nested.ctl.int_ctl & + V_IRQ_INJECTION_BITS_MASK; }
vmcb_mark_dirty(svm->vmcb, VMCB_INTR);
On Mon, Aug 16, 2021 at 04:02:34PM +0200, Paolo Bonzini wrote:
From: Maxim Levitsky mlevitsk@redhat.com
[ upstream commit 0f923e07124df069ba68d8bb12324398f4b6b709 ]
This is not a commit id in Linus's tree :(
And 5.12.y is long end-of-life, take a look at the front page of kernel.org for the active kernels.
thanks,
greg k-h
On 16/08/21 16:25, Greg KH wrote:
[ upstream commit 0f923e07124df069ba68d8bb12324398f4b6b709 ]
And 5.12.y is long end-of-life, take a look at the front page of kernel.org for the active kernels.
Ok, sorry I didn't notice that... it wasn't end of life when the issue was discovered. O:)
(Damn, the one time that we prepare all the backports in advance, we end up doing too many of them!)
Paolo
On Mon, Aug 16, 2021 at 05:04:58PM +0200, Paolo Bonzini wrote:
On 16/08/21 16:25, Greg KH wrote:
[ upstream commit 0f923e07124df069ba68d8bb12324398f4b6b709 ]
And 5.12.y is long end-of-life, take a look at the front page of kernel.org for the active kernels.
Ok, sorry I didn't notice that... it wasn't end of life when the issue was discovered. O:)
(Damn, the one time that we prepare all the backports in advance, we end up doing too many of them!)
You didn't do a 5.13.y version :(
Will the 5.12.y patches work for that tree?
thanks,
greg k-h
On Mon, 2021-08-16 at 17:11 +0200, Greg KH wrote:
On Mon, Aug 16, 2021 at 05:04:58PM +0200, Paolo Bonzini wrote:
On 16/08/21 16:25, Greg KH wrote:
[ upstream commit 0f923e07124df069ba68d8bb12324398f4b6b709 ]
And 5.12.y is long end-of-life, take a look at the front page of kernel.org for the active kernels.
Ok, sorry I didn't notice that... it wasn't end of life when the issue was discovered. O:)
(Damn, the one time that we prepare all the backports in advance, we end up doing too many of them!)
You didn't do a 5.13.y version :(
Will the 5.12.y patches work for that tree?
5.13 will more likely to work with the upstream version. I'll check it soon.
Best regards, Maxim Levitsky
thanks,
greg k-h
On Mon, 2021-08-16 at 17:56 +0200, Paolo Bonzini wrote:
On 16/08/21 17:37, Maxim Levitsky wrote:
5.13 will more likely to work with the upstream version. I'll check it soon.
There are a couple context differences so I've already tested it and sent it out.
Thank you! Best regards, Maxim Levitsky
Paolo
linux-stable-mirror@lists.linaro.org