From patchwork Mon Apr 14 15:38:20 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 338993 X-Patchwork-Delegate: trini@ti.com Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from theia.denx.de (theia.denx.de [85.214.87.163]) by ozlabs.org (Postfix) with ESMTP id 60A2E14007B for ; Tue, 15 Apr 2014 01:46:30 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 4020C4B60F; Mon, 14 Apr 2014 17:46:27 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at theia.denx.de Received: from theia.denx.de ([127.0.0.1]) by localhost (theia.denx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puO4V6AI75gX; Mon, 14 Apr 2014 17:46:27 +0200 (CEST) Received: from theia.denx.de (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id BCBEB4B601; Mon, 14 Apr 2014 17:46:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id F13734B601 for ; Mon, 14 Apr 2014 17:46:19 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at theia.denx.de Received: from theia.denx.de ([127.0.0.1]) by localhost (theia.denx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhcR09slIVPy for ; Mon, 14 Apr 2014 17:46:16 +0200 (CEST) X-Greylist: delayed 469 seconds by postgrey-1.27 at theia; Mon, 14 Apr 2014 17:46:13 CEST X-policyd-weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 (only DNSBL check requested) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by theia.denx.de (Postfix) with ESMTPS id 3E45E4B600 for ; Mon, 14 Apr 2014 17:46:12 +0200 (CEST) Received: by mail-ob0-f174.google.com with SMTP id gq1so982956obb.19 for ; Mon, 14 Apr 2014 08:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=O833ctmAWHno4TXvw7p9sKNwOpxsd9guCZI+306j7Ak=; b=I/JdjhNmzMwWeUzvhawu+dl6PmnmeJ+kysnzd6JJd+zlrTmz2Jb33Ld8rJx9MsCG/y 7JmtW/psKY8hw9xkWMhOuoYDeTDEGLNJvGdu2ieJTCrWMvUyo3OkP4gWXpdhe02yoLTY keLRLJq1xwvxQCniVr/HSfyHjbO2WCjgxKUnqBiO51KAcFaTiu9Od+gzJErACa+G6x/P 5+TJrscVko/779mlVBMnp6dnSTJo1CrrX+RV1NoBfBSItMTJRXOgGGqTJmXKISuYSuUq zbkNGaqBkf7xWS7/DReXks3w+hG4ZTFbLPD0MVBCj6wO40dsX0HTXDmL4wjYmGcgAIPf dyhQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=O833ctmAWHno4TXvw7p9sKNwOpxsd9guCZI+306j7Ak=; b=aoEuJo5Q/gJXXI/PDNpRSzzkSix2sNt5REJndEthmarFJSAgMtP+l5lkQy8888Vds2 pLrjOyLRQ4W8uk0kdN/Y4e0kcdVcWT2XWmIL7S1yxeLVQroV22FL7weaWA1I1a2ZQ1+t nKG3eVTz7NmUp4NbwEsN9VP6mVasYmB6CZsqU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=O833ctmAWHno4TXvw7p9sKNwOpxsd9guCZI+306j7Ak=; b=MmFF0I7Xjjl9KURRwVSuu9dmBDCnjeZi18weiY/MpMVNkpEDqZTYTZkls4jaQcwyJk xcxtMrEXhoCWIsk/Tx9XkStkQ5aVtk6AqyGjZlI8mEAttxfVmTote3wS9vcdAjXZ4qn1 YvTFbl9pjyjwYBqX051sife1iLmj+qOYvKkLx/Yo8wQwD2u99Ptq0iFg62qbnr2S1T6K W/WFiFSsvV1Miz5OjjEmpgN3tNZKCnWj3BFbj8ROOkkoif/SJanWeQFGYdv3RsubkoMl dnhnjZ6QueudfKrUoNLjZWxmsyr1PQwJIY0Az8ce/UMeHizyrWCds/5ClYFc+Niecnga tGEA== X-Gm-Message-State: ALoCoQlTvYGo5NN39wDVwTPUYnG6vwpeH5LKJiKnQ94h/eaU3AOvgi3CWmolVl2bwhcipKCwMl9wuUarIOLDvwj/cm/B5wtKfgKKnKO21wtayeui+SKH2V+aKzlnT10ThzJpCweELQdv3dqnJZLmgiJ7g7mrqIqcm4CV1BujS2gh5IoN/wX4IwOd7QUOFWajdWHU4SdFjX14 MIME-Version: 1.0 X-Received: by 10.60.144.200 with SMTP id so8mr34943425oeb.31.1397489900949; Mon, 14 Apr 2014 08:38:20 -0700 (PDT) Received: by 10.182.226.163 with HTTP; Mon, 14 Apr 2014 08:38:20 -0700 (PDT) In-Reply-To: <534BA18B.5050509@arcor.de> References: <5347BBBC.9000806@arcor.de> <20140411104350.BA22938042D@gemini.denx.de> <534B7BA4.8070100@arcor.de> <534BA18B.5050509@arcor.de> Date: Mon, 14 Apr 2014 08:38:20 -0700 X-Google-Sender-Auth: M0-C297JN3jEUC6Lav_7OOlM4mQ Message-ID: From: Kees Cook To: =?UTF-8?Q?Matthias_Wei=C3=9Fer?= Cc: U-Boot-Users ML Subject: Re: [U-Boot] Strange CFI flash problem X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: u-boot-bounces@lists.denx.de Errors-To: u-boot-bounces@lists.denx.de On Mon, Apr 14, 2014 at 1:51 AM, Matthias Weißer 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.9000806@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 > 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 > Acked-by: Simon Glass > > 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? Tested-by: Matthias Weißer --- From: Kees Cook Subject: [PATCH] bootm: set max output for LZO The LZO decompressor wasn't initializing the maximum output size. Reported-by: Matthias Weißer Signed-off-by: Kees Cook --- 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);