[Qemu-devel] [PATCH] spapr: sanity check size of the CAS buffer

Greg Kurz posted 1 patch 6 years, 6 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/150710775137.16096.2606042109300213433.stgit@bahia.lan
Test checkpatch passed
Test docker passed
Test s390x passed
hw/ppc/spapr.c |    7 +++++++
1 file changed, 7 insertions(+)
[Qemu-devel] [PATCH] spapr: sanity check size of the CAS buffer
Posted by Greg Kurz 6 years, 6 months ago
The CAS buffer is provided by SLOF. A broken SLOF could pass a silly
size: either smaller than the diff header, in which case the current
code will try to allocate 16 Exabytes of memory and g_malloc0() will
abort, or bigger than the maximum memory provisioned for SLOF (ie,
40 Megabytes), which doesn't make sense. Both cases indicate that
SLOF has a bug.

Let's print out an explicit error message and exit since rebooting as
we do with other errors would only result in a reset loop.

Signed-off-by: Greg Kurz <groug@kaod.org>
---
 hw/ppc/spapr.c |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index b284e0b9d43e..1a2ca8a22b6d 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -819,6 +819,13 @@ int spapr_h_cas_compose_response(sPAPRMachineState *spapr,
         return 1;
     }
 
+    if (size < sizeof(hdr) || size > FW_MAX_SIZE) {
+        error_report("SLOF provided an unexpected CAS buffer size "
+                     TARGET_FMT_lu " (min: %lu, max: %u)",
+                     size, sizeof(hdr), FW_MAX_SIZE);
+        exit(EXIT_FAILURE);
+    }
+
     size -= sizeof(hdr);
 
     /* Create skeleton */


Re: [Qemu-devel] [PATCH] spapr: sanity check size of the CAS buffer
Posted by David Gibson 6 years, 6 months ago
On Wed, Oct 04, 2017 at 11:02:31AM +0200, Greg Kurz wrote:
> The CAS buffer is provided by SLOF. A broken SLOF could pass a silly
> size: either smaller than the diff header, in which case the current
> code will try to allocate 16 Exabytes of memory and g_malloc0() will
> abort, or bigger than the maximum memory provisioned for SLOF (ie,
> 40 Megabytes), which doesn't make sense. Both cases indicate that
> SLOF has a bug.

Actually, it's much worse than that: SLOF is what's *expected* to call
H_CAS, but nothing actually prevents anything in the guest from
calling it and blowing up qemu.  Or, worse, allocating a large amount
of memory outside the guest's address space.

> Let's print out an explicit error message and exit since rebooting as
> we do with other errors would only result in a reset loop.
> 
> Signed-off-by: Greg Kurz <groug@kaod.org>

Applied.

> ---
>  hw/ppc/spapr.c |    7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index b284e0b9d43e..1a2ca8a22b6d 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -819,6 +819,13 @@ int spapr_h_cas_compose_response(sPAPRMachineState *spapr,
>          return 1;
>      }
>  
> +    if (size < sizeof(hdr) || size > FW_MAX_SIZE) {
> +        error_report("SLOF provided an unexpected CAS buffer size "
> +                     TARGET_FMT_lu " (min: %lu, max: %u)",
> +                     size, sizeof(hdr), FW_MAX_SIZE);
> +        exit(EXIT_FAILURE);
> +    }
> +
>      size -= sizeof(hdr);
>  
>      /* Create skeleton */
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson