Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751518AbdILNMq convert rfc822-to-8bit (ORCPT ); Tue, 12 Sep 2017 09:12:46 -0400 Received: from mail.free-electrons.com ([62.4.15.54]:36641 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751332AbdILNMp (ORCPT ); Tue, 12 Sep 2017 09:12:45 -0400 Date: Tue, 12 Sep 2017 15:12:36 +0200 From: Boris Brezillon To: Geert Uytterhoeven Cc: Cyrille Pitchen , Marek Vasut , MTD Maling List , Brian Norris , David Woodhouse , Richard Weinberger , "linux-kernel@vger.kernel.org" Subject: Re: [DEBUG] mtd: spi-nor: dump DWORDs of the Basic Flash Parameter Table Message-ID: <20170912151236.33c5ad8f@bbrezillon> In-Reply-To: References: <20170907185456.4631-1-cyrille.pitchen@wedev4u.fr> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3388 Lines: 95 Hi Geert, On Mon, 11 Sep 2017 10:58:36 +0200 Geert Uytterhoeven wrote: > Hi Cyrille, > > On Thu, Sep 7, 2017 at 9:28 PM, Cyrille Pitchen > wrote: > >> Can you apply this patch on your tree then report me what was printed, please? > >> I have an idea of the root cause of your issue then a potential work-around > >> but I first need to validate my assumption to confirm that the work-around > >> would actually work. > > +m25p80 spi0.0: DWORD1 = 0xffffffff > +m25p80 spi0.0: DWORD2 = 0xffffffff > +m25p80 spi0.0: DWORD3 = 0xffffffff > +m25p80 spi0.0: DWORD4 = 0xffffffff > +m25p80 spi0.0: DWORD5 = 0xffffffff > +m25p80 spi0.0: DWORD6 = 0xffffffff > +m25p80 spi0.0: DWORD7 = 0xffffffff > +m25p80 spi0.0: DWORD8 = 0xffffffff > +m25p80 spi0.0: DWORD9 = 0xffffffff > +m25p80 spi0.0: DWORD10 = 0x00000000 > +m25p80 spi0.0: DWORD11 = 0x00000000 > +m25p80 spi0.0: DWORD12 = 0x00000000 > +m25p80 spi0.0: DWORD13 = 0x00000000 > +m25p80 spi0.0: DWORD14 = 0x00000000 > +m25p80 spi0.0: DWORD15 = 0x00000000 > +m25p80 spi0.0: DWORD16 = 0x00000000 > +m25p80 spi0.0: BFPT version 1.0 (length = 9) > > > If you could also dump the value of the 'addr' argument of > > spi_nor_read_sfdp_dma_unsafe() just before the for () loop below in the > > very same function. Actually, I suspect the SFDP tables of your SPI NOR > > +m25p80 spi0.0: addr = 0x448 > > > memory sample to have been programmed with invalid values, neither > > compliant with the JEDEC JESD216 specification nor with the Cypress > > datasheet for this memory part. > > Sounds plausible. > I get the same values when disabling DMA, so it's not due to bad DMA handling. > All Renesas boards I have local or remote access to have spansion,s25fl512s. Can you try with the following patch? Thanks, Boris --->8--- >From 000ff63fdb149d87d755483f5edc0aba010da6b4 Mon Sep 17 00:00:00 2001 From: Boris Brezillon Date: Tue, 12 Sep 2017 15:10:35 +0200 Subject: [PATCH] mtd: spi-nor: Check consistency of the memory size extracted from the SFDP One field of the flash parameter table contains information about the flash device size. Most of the time the data extracted from this field is valid, but sometimes the BFPT section of the SFDP table is corrupted or invalid and this field is set to 0xffffffff, thus resulting in an integer overflow when setting params->size. Since NOR devices are anayway always smaller than 2^64 bytes, we can easily stop the BFPT parsing if the size reported in this table is invalid. Signed-off-by: Boris Brezillon --- drivers/mtd/spi-nor/spi-nor.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index cf1d4a15e10a..665ccae1d090 100644 --- a/drivers/mtd/spi-nor/spi-nor.c +++ b/drivers/mtd/spi-nor/spi-nor.c @@ -2127,6 +2127,15 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor, params->size = bfpt.dwords[BFPT_DWORD(2)]; if (params->size & BIT(31)) { params->size &= ~BIT(31); + + /* + * Prevent overflows on params->size. Anyway, a NOR of 1^64 + * bytes is unlikely to exist so this error probably means + * the BFPT we are reading is corrupted/wrong. + */ + if (params->size > 63) + return -EINVAL; + params->size = 1ULL << params->size; } else { params->size++;