linux-kernel - Re: [bug] spi-nor not unlocking on Ubiquiti XW and WA

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] [day] [month] [year] [list]

Message-ID:
 <BN8PR06MB56046FE563174567FF7744AAC541A@BN8PR06MB5604.namprd06.prod.outlook.com>
Date: Tue, 1 Jul 2025 06:33:29 -0400
From: Jean-Marc Ranger <jmranger@...mail.com>
To: Michael Walle <mwalle@...nel.org>, tudor.ambarus@...aro.org,
 pratyush@...nel.org, miquel.raynal@...tlin.com, richard@....at,
 vigneshr@...com, linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Cc: tim.j.wilkinson@...il.com
Subject: Re: [bug] spi-nor not unlocking on Ubiquiti XW and WA

On 2025-07-01 03:07, Michael Walle wrote:
> On Mon Jun 30, 2025 at 7:50 PM CEST, Jean-Marc Ranger wrote:
>> On 2025-06-30 05:25, Michael Walle wrote:
>>> This seems to be due to the use of the uninitalized "mtd->size".
>>> Could you try the following patch which is based on the latest
>>> next kernel. It replaces mtd->size with nor->params->size, so you
>>> could backport it to 6.6, but maybe it will apply anyway.
>>
>> Thank you so much for taking the time!
>>
>> Your patch applies automatically on 6.6.93, with minimal fuzzing and
>> offset changes. And it fixes the issue! Formally:
>> Tested-by: Jean-Marc Ranger <jmranger@...mail.com>
> 
> Great. I'll prepare a proper patch shortly.
> 
> But I have to wonder whether this flash is locked by default after
> each power-up or if it's just locked once after it comes out of the
> factory.
> 
> The MX25L12805D datasheet reads:
> 
>    BP3, BP2, BP1, BP0 bits. The Block Protect (BP3, BP2, BP1, BP0)
>    bits, non-volatile bits, indicate the protected area(as defined in
>    table 1) of the device to against the program/erase instruction
>    without hardware protection mode being set.
> 
> Does the bootloader enable the protection bits on each bootup? If
> that's the case be aware that the bits might wear out over time
> depending on how often that device is restarted ;) Likely won't
> happen but it's still not nice if the bootloader fights against what
> linux is doing (or the other way around).

My understanding is that it does. What was written when the same issue 
happened in the OpenWRT 22.03 to 23.05 transition a year ago might 
interest you: [1].

Since we're on the topic of locking bits in Macronix chips, I noticed 
yesterday that OpenWRT carries a small patch from 2021 on that topic: 
[2][3]. No request here, only FYI.

Jean-Marc

[1] https://github.com/openwrt/openwrt/pull/14237
[2] 
https://github.com/openwrt/openwrt/blob/main/target/linux/generic/pending-6.12/498-mtd-spi-nor-locking-support-for-MX25L6405D.patch
[3] 
https://github.com/openwrt/openwrt/blob/main/target/linux/generic/pending-6.6/498-mtd-spi-nor-locking-support-for-MX25L6405D.patch