From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 96E3BC433EF for ; Tue, 17 May 2022 20:47:31 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 141568425D; Tue, 17 May 2022 22:47:28 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="PkVOrdob"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 36D7084277; Tue, 17 May 2022 22:47:26 +0200 (CEST) Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 1DD0380762 for ; Tue, 17 May 2022 22:47:22 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=pali@kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 8659EB81C1C; Tue, 17 May 2022 20:47:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F3EB2C385B8; Tue, 17 May 2022 20:47:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1652820440; bh=NLk4wktz6opg8hTKwpktpVFx/yNEKvCW+TmHxcqe0jA=; h=From:To:Cc:Subject:Date:From; b=PkVOrdob1mwAtM/cAizMDqaOrglyk9bPHlieH5qSvHPcWCuyULbt4bUzVOP+B1NCY yjuT9M066Ip5tzDjvHS/MYjKS4b7c1XLle44mLfIDeQMeXRkZ37MtHU+BYDdEbdaTq 8w6yQj7DNaD8qs7v0TWVvdzpSHLfyWMUE/72KIiTzmj/fTVOcu35FrW15eu4g8/4FE vsK+uECIePj+V3ejAubTfKq188oVEI02kyyuWfDkraBURluqfAOrdfgUX7VPbc0UuB Q8kbWhVOGQM17sbrEWpPlYT8Gkx7jO4jkv/W8eA3IBJG7NVq39WgUbldwpCkjnRl+3 K7sCgMJiwXaRA== Received: by pali.im (Postfix) id 145267DA; Tue, 17 May 2022 22:47:17 +0200 (CEST) From: =?UTF-8?q?Pali=20Roh=C3=A1r?= To: Stefan Roese Cc: u-boot@lists.denx.de Subject: [PATCH] ubifs: Fix lockup/crash when reading files Date: Tue, 17 May 2022 22:45:28 +0200 Message-Id: <20220517204528.7277-1-pali@kernel.org> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean Commit b1a14f8a1c2e ("UBIFS: Change ubifsload to not read beyond the requested size") added optimization to do not read more bytes than it is really needed. But this commit introduced incorrect handling of the hole at the end of file. This logic cause U-Boot to crash or lockup when trying to read from the ubifs filesystem. When read_block() call returns -ENOENT error (not an error, but the hole) then dn-> structure is not filled and contain garbage. So using of dn->size for memcpy() argument cause that U-Boot tries to copy unspecified amount of bytes from possible unmapped memory. Which randomly cause lockup of P2020 CPU. Fix this issue by copying UBIFS_BLOCK_SIZE bytes from read buffer when dn->size is not available. UBIFS_BLOCK_SIZE is the size of the buffer itself and read_block() fills buffer by zeros when it returns -ENOENT. This patch fixes ubifsload on P2020. Fixes: b1a14f8a1c2e ("UBIFS: Change ubifsload to not read beyond the requested size") Signed-off-by: Pali Rohár --- Stefan, could you please look at this patch? Mentioned commit was introduced by you more than 11 years ago. I'm surprised that nobody hit this issue yet, but it looks like older U-Boot versions somehow filled small garbage number into dn->size and did not cause U-Boot lockup/crash. --- fs/ubifs/ubifs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c index d6be5c947d7e..d3026e310168 100644 --- a/fs/ubifs/ubifs.c +++ b/fs/ubifs/ubifs.c @@ -771,40 +771,42 @@ static int do_readpage(struct ubifs_info *c, struct inode *inode, buff = malloc_cache_aligned(UBIFS_BLOCK_SIZE); if (!buff) { printf("%s: Error, malloc fails!\n", __func__); err = -ENOMEM; break; } /* Read block-size into temp buffer */ ret = read_block(inode, buff, block, dn); if (ret) { err = ret; if (err != -ENOENT) { free(buff); break; } } if (last_block_size) dlen = last_block_size; + else if (ret) + dlen = UBIFS_BLOCK_SIZE; else dlen = le32_to_cpu(dn->size); /* Now copy required size back to dest */ memcpy(addr, buff, dlen); free(buff); } else { ret = read_block(inode, addr, block, dn); if (ret) { err = ret; if (err != -ENOENT) break; } } } if (++i >= UBIFS_BLOCKS_PER_PAGE) break; block += 1; addr += UBIFS_BLOCK_SIZE; -- 2.20.1