[U-Boot] [PATCH v5 0/9] Fix CVE-2018-18440 and CVE-2018-18439

[Simon Goldschmidt]

Hi Tom,

[truncated the CC list a bit since I got "too many recipients" errors 
last time]

Am 11.12.2018 um 14:31 schrieb Tom Rini:
> On Sun, Dec 09, 2018 at 09:45:13PM +0100, Simon Goldschmidt wrote:
> 
>> This series fixes CVE-2018-18440 ("insufficient boundary checks in
>> filesystem image load") by adding restrictions to the 'load'
>> command and fixes CVE-2018-18439 ("insufficient boundary checks in
>> network image boot") by adding restrictions to the tftp code.
>> The functions from lmb.c are used to setup regions of allowed and
>> reserved memory. Then, the file size to load is checked against these
>> addresses and loading the file is aborted if it would overwrite
>> reserved memory.
>>
>> The memory reservation code is reused from bootm/image.
> 
> So, thanks for doing all of this.  I'm sorry to dump a few problems on
> you now however.  First, we have a lot of fail to builds:
> https://travis-ci.org/trini/u-boot/builds/466333708

Ok, I'll check those. At first sight, the build errors seem to be 
identical in that 'fdt_get_resource' is missing. I'll check that config 
option.

> Second, giving this a run-time test on Raspberry Pi 3 (aarch64 mode) and
> trying to boot a regular Linux distro (this example is OpenEmbedded
> based but generic issue, boot.scr just loads Image to $loadaddr and
> booti's):
> U-Boot> run bootcmd
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> Found U-Boot script /boot.scr
> 389 bytes read in 2 ms (189.5 KiB/s)
> ## Executing script at 02000000
> 13298176 bytes read in 701 ms (18.1 MiB/s)
> ## Flattened Device Tree blob at 2effb500
>     Booting using the fdt blob at 0x2effb500
> ERROR: Failed to allocate 0x7ab5 bytes below 0xffffffff.
> Failed using fdt_high value for Device TreeFDT creation failed! hanging...### ERROR ### Please RESET the board ###
> 
> Switching the board to using bootm_size rather than
> initrd_high/fdt_high=0xffffffff does resolve the issue and I can boot,
> but it's still a case we need to fix.  Thanks!

Thanks for testing! Of course it's a case we need to fix! Would it be 
possible for you to do this run-time test again with the attached patch 
that enables DEBUG in lmb.c and dumps 'lmb' contents in the error case 
shown above?

Regards,
Simon

-------------- next part --------------
>From f004736d14725cc210ac39b974214082622081d3 Mon Sep 17 00:00:00 2001
From: Simon Goldschmidt <simon.k.r.goldschmidt at gmail.com>
Date: Tue, 11 Dec 2018 16:18:07 +0100
Subject: [PATCH] CVE-2018-18440: debug lmb failure

---
 common/image-fdt.c | 1 +
 lib/lmb.c          | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/common/image-fdt.c b/common/image-fdt.c
index 5c0d6db3fe..2d7e3237ea 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -186,6 +186,7 @@ int boot_relocate_fdt(struct lmb *lmb, char **of_flat_tree, ulong *of_size)
 							   (ulong)desired_addr);
 			if (of_start == NULL) {
 				puts("Failed using fdt_high value for Device Tree");
+				lmb_dump_all(lmb);
 				goto error;
 			}
 		} else {
diff --git a/lib/lmb.c b/lib/lmb.c
index ba680f883e..c4539c461d 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -5,7 +5,7 @@
  * Peter Bergner, IBM Corp.	June 2001.
  * Copyright (C) 2001 Peter Bergner.
  */
-
+#define DEBUG
 #include <common.h>
 #include <lmb.h>
 
-- 
2.17.1