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
>From f004736d14725cc210ac39b974214082622081d3 Mon Sep 17 00:00:00 2001
From: Simon Goldschmidt <simon.k.r.goldschm...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
