On Mon, Apr 14, 2014 at 1:51 AM, Matthias Weißer <weiss...@arcor.de> wrote: > Am 14.04.2014 08:09, schrieb Matthias Weißer: > >> Hi Wolfgang >> >> Am 11.04.2014 12:43, schrieb Wolfgang Denk: >>> >>> Dear Matthias, >>> >>> In message <5347bbbc.9000...@arcor.de> you wrote: >>>> >>>> >>>> we are currently trying to get an out-of-tree board based on 2013.01 >>>> back in sync with current master and observing a strange behavior which >>>> we think is located in the CFI flash system. If we load an image via >>>> tftp, copy it to flash and then try to run the image via bootm we see an >>>> error while decomressing: >>> >>> ... >>>> >>>> Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5 >>> >>> >>> Are you sure your malloc arena is big enough for LZO? Try if >>> increasing it helps... >> >> >> We increaded it from 4MB to 8MB and the behavior is still the same. >> >> We also observed a different behavior when tftping the image to RAM and >> then directly executing it without copying it to flash. It seems that >> the flash device (EN29GL256H) is then in some a mode (maybe auto-select) >> which prevents it from normal read operations which doesn't allow the >> flash driver of the OS come up. We never saw this with our old u-boot. >> If there are no ideas left we will have to bisect the problem. > > > Bisecting was successfull. The commit introducing the problem is > > commit ff9d2efdbf1b3b5263f81e843c6724b8bead7f1f > Author: Kees Cook <keesc...@chromium.org> > Date: Fri Aug 16 07:59:15 2013 -0700 > > lzo: correctly bounds-check output buffer > > This checks the size of the output buffer and fails if it was going to > overflow the buffer during lzo decompression. > > Signed-off-by: Kees Cook <keesc...@chromium.org> > Acked-by: Simon Glass <s...@chromium.org> > > This commit introduced the usage of the dst_len output parameter as > additional input parameter containing the maximum output buffer size. This > parameter isn't initialized in cmd_bootm.c: > > 454 #ifdef CONFIG_LZO > 455 case IH_COMP_LZO: { > 456 size_t size; > 457 > 458 printf(" Uncompressing %s ... ", type_name); > 459 > 460 ret = lzop_decompress(image_buf, image_len, load_buf, &size); > > Setting size to some big value (SZE_MAX is not avialable) fixed the behavior > but I am unsure if this is the correct solution. I think its hard to get the > max output buffer size at this point in cmd_bootm.c.
Does this work? --- From: Kees Cook <keesc...@chromium.org> Subject: [PATCH] bootm: set max output for LZO The LZO decompressor wasn't initializing the maximum output size. Reported-by: Matthias Weißer <weiss...@arcor.de> Signed-off-by: Kees Cook <keesc...@chromium.org> --- common/cmd_bootm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index 9751edc..c243a5b 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -453,7 +453,7 @@ static int bootm_load_os(bootm_headers_t *images, unsigned long *load_end, #endif /* CONFIG_LZMA */ #ifdef CONFIG_LZO case IH_COMP_LZO: { - size_t size; + size_t size = unc_len; printf(" Uncompressing %s ... ", type_name); -- 1.7.9.5 -- Kees Cook Chrome OS Security _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot