diff mbox series

[5.12.y] KVM: nSVM: avoid picking up unsupported bits from L2 in int_ctl (CVE-2021-3653)

Message ID 20210816140240.11399-6-pbonzini@redhat.com (mailing list archive)
State New, archived
Headers show
Series [5.12.y] KVM: nSVM: avoid picking up unsupported bits from L2 in int_ctl (CVE-2021-3653) | expand

Commit Message

Paolo Bonzini Aug. 16, 2021, 2:02 p.m. UTC 
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(-)

Comments

Greg KH Aug. 16, 2021, 2:25 p.m. UTC | #1 
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
Paolo Bonzini Aug. 16, 2021, 3:04 p.m. UTC | #2 
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
Greg KH Aug. 16, 2021, 3:11 p.m. UTC | #3 
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
Maxim Levitsky Aug. 16, 2021, 3:37 p.m. UTC | #4 
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
>
Paolo Bonzini Aug. 16, 2021, 3:56 p.m. UTC | #5 
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.

Paolo
Maxim Levitsky Aug. 16, 2021, 5:24 p.m. UTC | #6 
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
>
diff mbox series

Patch

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);