linux-kernel - Re: [PATCH v2] mtd: spi-nor: Check for zero erase size in spi_nor_find_best_erase

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <08d6657c-afa9-8739-196b-1e66d802e614@nokia.com>
Date:   Mon, 20 Dec 2021 10:46:43 +0100
From:   Alexander Sverdlin <alexander.sverdlin@...ia.com>
To:     Tudor.Ambarus@...rochip.com, linux-mtd@...ts.infradead.org
Cc:     p.yadav@...com, michael@...le.cc, miquel.raynal@...tlin.com,
        richard@....at, vigneshr@...com, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org
Subject: Re: [PATCH v2] mtd: spi-nor: Check for zero erase size in
 spi_nor_find_best_erase_type()

Hello Tudor,

On 18/12/2021 02:31, Tudor.Ambarus@...rochip.com wrote:
>> Erase can be zeroed in spi_nor_parse_4bait() or
>> spi_nor_init_non_uniform_erase_map(). In practice it happened with
>> mt25qu256a, which supports 4K, 32K, 64K erases with 3b address commands,
>> but only 4K and 64K erase with 4b address commands.
> 
> :D
> 
>>
>> Fixes: dc92843159a7 ("mtd: spi-nor: fix erase_type array to indicate current map conf")
>> Cc: stable@...r.kernel.org
>> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@...ia.com>
>> ---
>> Changes in v2:
>> erase->opcode -> erase->size
>>
>>  drivers/mtd/spi-nor/core.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>> index 88dd090..183ea9d 100644
>> --- a/drivers/mtd/spi-nor/core.c
>> +++ b/drivers/mtd/spi-nor/core.c
>> @@ -1400,6 +1400,8 @@ spi_nor_find_best_erase_type(const struct spi_nor_erase_map *map,
>>                         continue;
>>
>>                 erase = &map->erase_type[i];
>> +               if (!erase->size)
>> +                       continue;
> 
> I need a bit of context here. Does mt25qu256a has a uniform erase layout?

You caught me, the bug will not be visible with this flash type without the patch
which has been ignored for long time:
https://www.spinics.net/lists/linux-mtd/msg11510.html

I however run the above patch because of the reasons described in the commit message.
Nevertheless, the bug fixed now remains a bug no matter what triggers it.

> i.e. Does your flash has sectors of more than one size or does not allow
> the 4K and 64K erase types to be applied on all sectors in the 4B case?
> If no, you should have been in the spi_nor_has_uniform_erase() case, and
> if this case does not suit you, maybe we should update the code for this
> specific case instead.
> 
> On a short look I see that this flash defines just BFPT and 4BAIT table,
> so no SMPT. It looks like you're forcing the flash to behave as it had defined
> SMPT. Am I wrong?
> 
> Also, should we update the region's erase mask instead and mask out the
> unsupported erase type? I would love to hear more about your use case.

-- 
Best regards,
Alexander Sverdlin.