Blame SOURCES/CVE-2021-37576.patch

e6c5ce
From 742fee241938f6089d67c4e779ba0d608a9d88e3 Mon Sep 17 00:00:00 2001
e6c5ce
From: Joe Lawrence <joe.lawrence@redhat.com>
e6c5ce
Date: Mon, 30 Aug 2021 16:54:36 -0400
e6c5ce
Subject: [KPATCH CVE-2021-37576] powerpc: kpatch fixes for CVE-2021-37576
e6c5ce
e6c5ce
Kernels:
e6c5ce
4.18.0-305.el8
e6c5ce
4.18.0-305.3.1.el8_4
e6c5ce
4.18.0-305.7.1.el8_4
e6c5ce
4.18.0-305.10.2.el8_4
e6c5ce
4.18.0-305.12.1.el8_4
e6c5ce
e6c5ce
arches: ppc64le
e6c5ce
Changes since last build:
e6c5ce
[ppc64le]:
e6c5ce
book3s_rtas.o: changed function: kvmppc_rtas_hcall
e6c5ce
e6c5ce
---------------------------
e6c5ce
e6c5ce
Kernels:
e6c5ce
4.18.0-305.el8
e6c5ce
4.18.0-305.3.1.el8_4
e6c5ce
4.18.0-305.7.1.el8_4
e6c5ce
4.18.0-305.10.2.el8_4
e6c5ce
4.18.0-305.12.1.el8_4
e6c5ce
e6c5ce
Modifications: none
e6c5ce
Approved-by: Yannick Cote (@ycote1)
e6c5ce
Approved-by: Artem Savkov (@artem.savkov)
e6c5ce
KPATCH-MR: https://gitlab.com/kpatch-dev/rhel-8/-/merge_requests/2
e6c5ce
e6c5ce
KT0 test PASS: https://beaker.engineering.redhat.com/jobs/5756102
e6c5ce
for kpatch-patch-4_18_0-305-1-5.el8 scratch build:
e6c5ce
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=39394966
e6c5ce
e6c5ce
commit 82faab596fc8f92648f20e2fbc4211557b115c13
e6c5ce
Author: Jon Maloy <jmaloy@redhat.com>
e6c5ce
Date:   Thu Aug 12 19:22:51 2021 -0400
e6c5ce
e6c5ce
    KVM: PPC: Book3S: Fix H_RTAS rets buffer overflow
e6c5ce
e6c5ce
    Bugzilla: https://bugzilla.redhat.com/1988225
e6c5ce
    Upstream Status: Merged
e6c5ce
    Build Info: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=38936146
e6c5ce
    CVE: CVE-2021-37576
e6c5ce
e6c5ce
    commit f62f3c20647ebd5fb6ecb8f0b477b9281c44c10a
e6c5ce
    Author: Nicholas Piggin <npiggin@gmail.com>
e6c5ce
    Date:   Tue Jul 20 20:43:09 2021 +1000
e6c5ce
e6c5ce
        KVM: PPC: Book3S: Fix H_RTAS rets buffer overflow
e6c5ce
e6c5ce
        The kvmppc_rtas_hcall() sets the host rtas_args.rets pointer based on
e6c5ce
        the rtas_args.nargs that was provided by the guest. That guest nargs
e6c5ce
        value is not range checked, so the guest can cause the host rets pointer
e6c5ce
        to be pointed outside the args array. The individual rtas function
e6c5ce
        handlers check the nargs and nrets values to ensure they are correct,
e6c5ce
        but if they are not, the handlers store a -3 (0xfffffffd) failure
e6c5ce
        indication in rets[0] which corrupts host memory.
e6c5ce
e6c5ce
        Fix this by testing up front whether the guest supplied nargs and nret
e6c5ce
        would exceed the array size, and fail the hcall directly without storing
e6c5ce
        a failure indication to rets[0].
e6c5ce
e6c5ce
        Also expand on a comment about why we kill the guest and try not to
e6c5ce
        return errors directly if we have a valid rets[0] pointer.
e6c5ce
e6c5ce
        Fixes: 8e591cb72047 ("KVM: PPC: Book3S: Add infrastructure to implement kernel-side RTAS calls")
e6c5ce
        Cc: stable@vger.kernel.org # v3.10+
e6c5ce
        Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
e6c5ce
        Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
e6c5ce
        Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
e6c5ce
e6c5ce
    Signed-off-by: Jon Maloy <jmaloy@redhat.com>
e6c5ce
e6c5ce
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
e6c5ce
---
e6c5ce
 arch/powerpc/kvm/book3s_rtas.c | 25 ++++++++++++++++++++++---
e6c5ce
 1 file changed, 22 insertions(+), 3 deletions(-)
e6c5ce
e6c5ce
diff --git a/arch/powerpc/kvm/book3s_rtas.c b/arch/powerpc/kvm/book3s_rtas.c
e6c5ce
index ceccacbf028e..52095f765e32 100644
e6c5ce
--- a/arch/powerpc/kvm/book3s_rtas.c
e6c5ce
+++ b/arch/powerpc/kvm/book3s_rtas.c
e6c5ce
@@ -245,6 +245,17 @@ int kvmppc_rtas_hcall(struct kvm_vcpu *vcpu)
e6c5ce
 	 * value so we can restore it on the way out.
e6c5ce
 	 */
e6c5ce
 	orig_rets = args.rets;
e6c5ce
+	if (be32_to_cpu(args.nargs) >= ARRAY_SIZE(args.args)) {
e6c5ce
+		/*
e6c5ce
+		 * Don't overflow our args array: ensure there is room for
e6c5ce
+		 * at least rets[0] (even if the call specifies 0 nret).
e6c5ce
+		 *
e6c5ce
+		 * Each handler must then check for the correct nargs and nret
e6c5ce
+		 * values, but they may always return failure in rets[0].
e6c5ce
+		 */
e6c5ce
+		rc = -EINVAL;
e6c5ce
+		goto fail;
e6c5ce
+	}
e6c5ce
 	args.rets = &args.args[be32_to_cpu(args.nargs)];
e6c5ce
 
e6c5ce
 	mutex_lock(&vcpu->kvm->arch.rtas_token_lock);
e6c5ce
@@ -272,9 +283,17 @@ int kvmppc_rtas_hcall(struct kvm_vcpu *vcpu)
e6c5ce
 fail:
e6c5ce
 	/*
e6c5ce
 	 * We only get here if the guest has called RTAS with a bogus
e6c5ce
-	 * args pointer. That means we can't get to the args, and so we
e6c5ce
-	 * can't fail the RTAS call. So fail right out to userspace,
e6c5ce
-	 * which should kill the guest.
e6c5ce
+	 * args pointer or nargs/nret values that would overflow the
e6c5ce
+	 * array. That means we can't get to the args, and so we can't
e6c5ce
+	 * fail the RTAS call. So fail right out to userspace, which
e6c5ce
+	 * should kill the guest.
e6c5ce
+	 *
e6c5ce
+	 * SLOF should actually pass the hcall return value from the
e6c5ce
+	 * rtas handler call in r3, so enter_rtas could be modified to
e6c5ce
+	 * return a failure indication in r3 and we could return such
e6c5ce
+	 * errors to the guest rather than failing to host userspace.
e6c5ce
+	 * However old guests that don't test for failure could then
e6c5ce
+	 * continue silently after errors, so for now we won't do this.
e6c5ce
 	 */
e6c5ce
 	return rc;
e6c5ce
 }
e6c5ce
-- 
e6c5ce
2.31.1
e6c5ce
e6c5ce