From: Tom Rini Date: Fri, 14 Dec 2018 08:27:26 -0500 Subject: [U-Boot] [PATCH v5 0/9] Fix CVE-2018-18440 and CVE-2018-18439 In-Reply-To: References: <20181209204523.15419-1-simon.k.r.goldschmidt@gmail.com> <20181211133104.GP8702@bill-the-cat> <2b838a92-1a19-b88b-635a-a83d364d983f@gmail.com> <20181211201030.GW8702@bill-the-cat> <82abee77-7b4e-b34f-d96d-d8f11380c343@gmail.com> Message-ID: <20181214132726.GF8702@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, Dec 14, 2018 at 02:06:38PM +0100, Simon Goldschmidt wrote: > On Tue, Dec 11, 2018 at 10:05 PM Simon Goldschmidt > wrote: > > > > Am 11.12.2018 um 21:10 schrieb Tom Rini: > > > On Tue, Dec 11, 2018 at 04:19:44PM +0100, Simon Goldschmidt wrote: > > >> 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. > > > > The function 'fdt_get_resource' was the only match that I could find to > > decode register address + size from fdt. However, it resides in > > 'lib/fdtdec.c' which is only linked for OF_CONTROL. This seems strange > > as it is a read-access function to a dts and it can be used when > > booting, too. What would be the way to go here, move this to a different > > file or compile 'lib/fdtdec.c' depending on CONFIG_FIT or something? > > > > 2nd fail seems to be in 'test/py' tests. I'll dig into that, too. > > > > >> > > >>> 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? > > > > > > Here. Note that I'm sure you can replicate this anywhere by setting > > > initrd_high / fdt_high to 0xffffffff. > > > > OK, thanks for this additional output. I cannot reproduce this in the > > tests though. I'll have to check this with my hardware probably, but I > > hope it's not related to 64 bit... > > > > Regards, > > Simon > > > > > U-Boot> run bootcmd > > > switch to partitions #0, OK > > > mmc0 is current device > > > Scanning mmc 0:1... > > > Found U-Boot script /boot.scr > > > lmb_dump_all: > > > memory.cnt = 0x1 > > > memory.size = 0x0 > > > memory.reg[0x0].base = 0x0 > > > .size = 0x3b400000 > > > > > > reserved.cnt = 0x2 > > > reserved.size = 0x0 > > > reserved.reg[0x0].base = 0x0 > > > .size = 0x1000 > > > reserved.reg[0x1].base = 0x3af46e50 > > > .size = 0x4b91b0 > > > 389 bytes read in 28 ms (12.7 KiB/s) > > > ## Executing script at 02000000 > > > lmb_dump_all: > > > memory.cnt = 0x1 > > > memory.size = 0x0 > > > memory.reg[0x0].base = 0x0 > > > .size = 0x3b400000 > > > > > > reserved.cnt = 0x2 > > > reserved.size = 0x0 > > > reserved.reg[0x0].base = 0x0 > > > .size = 0x1000 > > > reserved.reg[0x1].base = 0x3af46a20 > > > .size = 0x4b95e0 > > > 13298176 bytes read in 746 ms (17 MiB/s) > > > ## Flattened Device Tree blob at 2effb500 > > > Booting using the fdt blob at 0x2effb500 > > > ERROR: Failed to allocate 0x7ab5 bytes below 0xffffffff. > > Tom, this looks strange. You said you're running this in 64-bit mode > but here, fdt_high seems to be all ones in the lower 32 bit only. > That's probably because you're running both 32bit and 64bit on the > same target and that 'fdt_high' value got loaded with the environment? Yes, that's right. I run this Pi in both 32 and 64bit mode and the saved environment is from the 32bit side and fdt_high/initrd_high are, hah, oops, wrong. > Anyway, this was the reason I haven't found it. I did find it now and > it's a bug that's been in lmb.c like forever. I'll send a v6 soon. Thanks! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: