Message ID | 20230627193738.19596-5-william.zhang@broadcom.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp8436207vqr; Tue, 27 Jun 2023 12:54:53 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7STVlpDVbYghQKLaGOCmNF8Fk16u8IArUCWqiUFLrHyYX+71q0OyoBi1MgPBYOYG2VNtZP X-Received: by 2002:a05:6a20:4323:b0:105:6d0e:c046 with SMTP id h35-20020a056a20432300b001056d0ec046mr42197016pzk.26.1687895693107; Tue, 27 Jun 2023 12:54:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687895693; cv=none; d=google.com; s=arc-20160816; b=g7xNkZs/x80aI7AOFQwH2RwLvWkF9RxLJ5XoH6KIPTa7ry3mDVav1F/UjDHImygRxL sMsIWUGusfusDqAa+PH6zXjSvLS3dBi47m6JFM9uK4UYUi/WZJm8l40RFRTPWujy2U9f TJJrh6g7dTx+ZeI/HK54QhqN1w8OsY5hif1TsqgyHaFhjlzgD6suMqfUuMrjizseOyuu tEFTOuJpyWMYaW0B3Rxw8ItVPiytKS4+OSxDqtBZkoDtAZUIyWmh0oIrgrm8O+I5n+j/ 7t3IIN5vCkQ3P0MEnAas0PF35C84illYs41P2uPbmWZv7+xJUNjuJG1erP9Jd0Uf9HCp tlqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=iaXp4mrMe/jXAKy0jRBzak4I8/V0aXguqJa0gdgX48g=; fh=V5lgikJFjYeJdRk3kd9fIKVcjyByg7w8p+LYJYgJQFE=; b=OiS8xERmQqLghZ52lqUq8FQsPNXIpvNKbmH3VWgGcfkldZdGwgWfmv/45TA8AiqA37 Cq9ARmc2LYgndNEZ8gNIB+aaelQg+PmYVkfo0k/rt/6GuGmNo7fdKJmddC7U8lR4FQ4Z zw8fyh4nuXnDp4jXjxwQFRxap26DGj289DI8dhTJhqkt2vJG5vPaBrn0xYyKOryqCf4a +S6OYK9SrMGVzUypCREWffZ3B/3LF7n+TkjYPV8SMq+SfVGjE8+popp191+JlmwNyiiw k0nJKUlpw6MwglhccLU7iyl2+12ZslHzf8Kuk529YPfBYRL1zKAo4pcS1kC2/YjMmR6M J+fg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@broadcom.com header.s=google header.b=bw6IbBSq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=broadcom.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j72-20020a638b4b000000b0052ca7192647si8038367pge.548.2023.06.27.12.54.39; Tue, 27 Jun 2023 12:54:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@broadcom.com header.s=google header.b=bw6IbBSq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=broadcom.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230349AbjF0Tik (ORCPT <rfc822;nicolai.engesland@gmail.com> + 99 others); Tue, 27 Jun 2023 15:38:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51790 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230195AbjF0TiZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 27 Jun 2023 15:38:25 -0400 Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9AB0D1FC1 for <linux-kernel@vger.kernel.org>; Tue, 27 Jun 2023 12:38:22 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-1b7e66ff65fso30490535ad.0 for <linux-kernel@vger.kernel.org>; Tue, 27 Jun 2023 12:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1687894702; x=1690486702; h=mime-version:references:in-reply-to:message-id:date:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=iaXp4mrMe/jXAKy0jRBzak4I8/V0aXguqJa0gdgX48g=; b=bw6IbBSqh+nxxv8KlezHQ267LmMa24v0mn0cdGQp1HTA9Dsb8q0yr+M2UkaHihh+UN suwkhkrZokLrb22hsYzHIrNXvT/GU+8erOy0ofWdfufu1U2PkrTkTagKhYi6LDcemMYi SwJFK64t3YyOnt96w2w8Gif1yOCEx8nkYCY9M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687894702; x=1690486702; h=mime-version:references:in-reply-to:message-id:date:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=iaXp4mrMe/jXAKy0jRBzak4I8/V0aXguqJa0gdgX48g=; b=LwM86npRTLd1Bp23EcKM7oVmcVXHflWy/9jBcKwTwrNzApnFB27HLTVmcDl+EWn9q/ 6kY38AtgJjk/KrCREXesnR24nbpqvPlwtZ+gwak1fFMdNmyP0JOWr40kuKC/CoRU3vl2 Bb4k93a2OkZRpBXm4x922WiMKaUzXBAeDfJOCQD9RmDLsxCOfcE2ORqfuFCHdWC877rv wOkxrBW7trjzR4aP/OYt/8/Ka9X8ZJY7s1g9r+DjVsaYXGfJk64/0VH7zjPFSNZL03F8 IeaIKVOC/SNVnUjMnlv+otZHCL5NCiFsMVqLHlncOKK/Wxcen89fiVEzmgUd7LQvnCvs 6/rg== X-Gm-Message-State: AC+VfDydB3wkWXzUhzqEPze0ci4xab5SS2Hh+Fndf9cIXa9JEt3O3HcL 2ZztAP7iQBKgj9wucOdQzpaRYA== X-Received: by 2002:a17:902:7c06:b0:1b3:a928:18e8 with SMTP id x6-20020a1709027c0600b001b3a92818e8mr9757938pll.52.1687894702074; Tue, 27 Jun 2023 12:38:22 -0700 (PDT) Received: from ubuntu-22.localdomain ([192.19.222.250]) by smtp.gmail.com with ESMTPSA id g7-20020a1709026b4700b001b7f40a8959sm4986919plt.76.2023.06.27.12.38.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Jun 2023 12:38:20 -0700 (PDT) From: William Zhang <william.zhang@broadcom.com> To: Broadcom Kernel List <bcm-kernel-feedback-list@broadcom.com>, Linux MTD List <linux-mtd@lists.infradead.org> Cc: f.fainelli@gmail.com, rafal@milecki.pl, kursad.oney@broadcom.com, joel.peshkin@broadcom.com, computersforpeace@gmail.com, anand.gore@broadcom.com, dregan@mail.com, kamal.dasu@broadcom.com, tomer.yacoby@broadcom.com, dan.beygelman@broadcom.com, William Zhang <william.zhang@broadcom.com>, Florian Fainelli <florian.fainelli@broadcom.com>, Miquel Raynal <miquel.raynal@bootlin.com>, linux-kernel@vger.kernel.org, Vignesh Raghavendra <vigneshr@ti.com>, Richard Weinberger <richard@nod.at>, Kamal Dasu <kdasu.kdev@gmail.com> Subject: [PATCH v3 4/5] mtd: rawnand: brcmnand: Fix potential out-of-bounds access in oob write Date: Tue, 27 Jun 2023 12:37:37 -0700 Message-Id: <20230627193738.19596-5-william.zhang@broadcom.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230627193738.19596-1-william.zhang@broadcom.com> References: <20230627193738.19596-1-william.zhang@broadcom.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000027474205ff219c80" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1769886913996801767?= X-GMAIL-MSGID: =?utf-8?q?1769886913996801767?= |
Series |
mtd: rawnand: brcmnand: driver and doc updates
|
|
Commit Message
William Zhang
June 27, 2023, 7:37 p.m. UTC
When the oob buffer length is not in multiple of words, the oob write function does out-of-bounds read on the oob source buffer at the last iteration. Fix that by always checking length limit on the oob buffer read and fill with 0xff when reaching the end of the buffer to the oob registers. Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller") Signed-off-by: William Zhang <william.zhang@broadcom.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> --- Changes in v3: - Fix kernel test robot sparse warning: drivers/mtd/nand/raw/brcmnand/brcmnand.c:1500:54: sparse: expected unsigned int [usertype] data drivers/mtd/nand/raw/brcmnand/brcmnand.c:1500:54: sparse: got restricted __be32 [usertype] Changes in v2: - Handle the remaining unaligned oob data after the oob data write loop drivers/mtd/nand/raw/brcmnand/brcmnand.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
Comments
Hi William, william.zhang@broadcom.com wrote on Tue, 27 Jun 2023 12:37:37 -0700: > When the oob buffer length is not in multiple of words, the oob write > function does out-of-bounds read on the oob source buffer at the last > iteration. Fix that by always checking length limit on the oob buffer > read and fill with 0xff when reaching the end of the buffer to the oob > registers. > > Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller") Wrong Fixes. Missing Cc stable. > Signed-off-by: William Zhang <william.zhang@broadcom.com> > Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> > > --- > > Changes in v3: > - Fix kernel test robot sparse warning: > drivers/mtd/nand/raw/brcmnand/brcmnand.c:1500:54: sparse: expected unsigned int [usertype] data > drivers/mtd/nand/raw/brcmnand/brcmnand.c:1500:54: sparse: got restricted __be32 [usertype] > > Changes in v2: > - Handle the remaining unaligned oob data after the oob data write loop > > drivers/mtd/nand/raw/brcmnand/brcmnand.c | 13 +++++++++++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c > index ea03104692bf..407bf79cbaf4 100644 > --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c > +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c > @@ -1477,19 +1477,28 @@ static int write_oob_to_regs(struct brcmnand_controller *ctrl, int i, > const u8 *oob, int sas, int sector_1k) > { > int tbytes = sas << sector_1k; > - int j; > + int j, k = 0; > + u32 last = 0xffffffff; > + u8 *plast = (u8 *)&last; > > /* Adjust OOB values for 1K sector size */ > if (sector_1k && (i & 0x01)) > tbytes = max(0, tbytes - (int)ctrl->max_oob); > tbytes = min_t(int, tbytes, ctrl->max_oob); > > - for (j = 0; j < tbytes; j += 4) > + for (j = 0; (j + 3) < tbytes; j += 4) Maybe a comment here as well to mention that you stop at the last iteration? Otherwise, just reading the line does not make you choice obvious. > oob_reg_write(ctrl, j, > (oob[j + 0] << 24) | > (oob[j + 1] << 16) | > (oob[j + 2] << 8) | > (oob[j + 3] << 0)); > + > + while (j < tbytes) > + plast[k++] = oob[j++]; > + > + if (tbytes & 0x3) > + oob_reg_write(ctrl, (tbytes & ~0x3), (__force u32)cpu_to_be32(last)); > + > return tbytes; > } > Thanks, Miquèl
Hi Miquel, On 07/04/2023 08:28 AM, Miquel Raynal wrote: > Hi William, > > william.zhang@broadcom.com wrote on Tue, 27 Jun 2023 12:37:37 -0700: > >> When the oob buffer length is not in multiple of words, the oob write >> function does out-of-bounds read on the oob source buffer at the last >> iteration. Fix that by always checking length limit on the oob buffer >> read and fill with 0xff when reaching the end of the buffer to the oob >> registers. >> >> Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller") > > Wrong Fixes. Same here. The function write_oob_to_regs was added by this commit and no change since then. > > Missing Cc stable. Will add > >> Signed-off-by: William Zhang <william.zhang@broadcom.com> >> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> >> >> --- >> >> Changes in v3: >> - Fix kernel test robot sparse warning: >> drivers/mtd/nand/raw/brcmnand/brcmnand.c:1500:54: sparse: expected unsigned int [usertype] data >> drivers/mtd/nand/raw/brcmnand/brcmnand.c:1500:54: sparse: got restricted __be32 [usertype] >> >> Changes in v2: >> - Handle the remaining unaligned oob data after the oob data write loop >> >> drivers/mtd/nand/raw/brcmnand/brcmnand.c | 13 +++++++++++-- >> 1 file changed, 11 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c >> index ea03104692bf..407bf79cbaf4 100644 >> --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c >> +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c >> @@ -1477,19 +1477,28 @@ static int write_oob_to_regs(struct brcmnand_controller *ctrl, int i, >> const u8 *oob, int sas, int sector_1k) >> { >> int tbytes = sas << sector_1k; >> - int j; >> + int j, k = 0; >> + u32 last = 0xffffffff; >> + u8 *plast = (u8 *)&last; >> >> /* Adjust OOB values for 1K sector size */ >> if (sector_1k && (i & 0x01)) >> tbytes = max(0, tbytes - (int)ctrl->max_oob); >> tbytes = min_t(int, tbytes, ctrl->max_oob); >> >> - for (j = 0; j < tbytes; j += 4) >> + for (j = 0; (j + 3) < tbytes; j += 4) > > Maybe a comment here as well to mention that you stop at the last > iteration? Otherwise, just reading the line does not make you choice > obvious. > Will add comment. >> oob_reg_write(ctrl, j, >> (oob[j + 0] << 24) | >> (oob[j + 1] << 16) | >> (oob[j + 2] << 8) | >> (oob[j + 3] << 0)); >> + >> + while (j < tbytes) >> + plast[k++] = oob[j++]; >> + >> + if (tbytes & 0x3) >> + oob_reg_write(ctrl, (tbytes & ~0x3), (__force u32)cpu_to_be32(last)); >> + >> return tbytes; >> } >> > > > Thanks, > Miquèl >
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c index ea03104692bf..407bf79cbaf4 100644 --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c @@ -1477,19 +1477,28 @@ static int write_oob_to_regs(struct brcmnand_controller *ctrl, int i, const u8 *oob, int sas, int sector_1k) { int tbytes = sas << sector_1k; - int j; + int j, k = 0; + u32 last = 0xffffffff; + u8 *plast = (u8 *)&last; /* Adjust OOB values for 1K sector size */ if (sector_1k && (i & 0x01)) tbytes = max(0, tbytes - (int)ctrl->max_oob); tbytes = min_t(int, tbytes, ctrl->max_oob); - for (j = 0; j < tbytes; j += 4) + for (j = 0; (j + 3) < tbytes; j += 4) oob_reg_write(ctrl, j, (oob[j + 0] << 24) | (oob[j + 1] << 16) | (oob[j + 2] << 8) | (oob[j + 3] << 0)); + + while (j < tbytes) + plast[k++] = oob[j++]; + + if (tbytes & 0x3) + oob_reg_write(ctrl, (tbytes & ~0x3), (__force u32)cpu_to_be32(last)); + return tbytes; }