[PATCH v2] mtd: spi-nor: Fix quad-enable for flashes with QER bit in SR1
sashiko-bot at kernel.org
sashiko-bot at kernel.org
Fri Sep 11 03:52:44 PDT 2026
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] spi_nor_read_sr1_and_sr2() leaves sr[1] uninitialized when read_sr2 is unsupported, leading to uninitialized stack memory use in callers and spurious -EIO errors.
--
commit d557e6d5e442dbe4ee4d997bc0f3bb6190d5ba2c
Author: Miquel Raynal <miquel.raynal at bootlin.com>
mtd: spi-nor: Fix quad-enable for flashes with QER bit in SR1
Some flashes do set BFPT_DWORD15_QER_SR1_BIT6, which means they do not
have an SR2 to read from/write to. The generic QE helper has forgotten
about the Macronix case, which causes booting to fail. This fix makes
sure SR2 reads just return 0 if unsupported to accommodate this situation.
Link: https://lore.kernel.org/linux-mtd/178876719232.3543902.14451625037676421254.b4-ty@b4/T/#m5bc4ba6776436f2870ced0eb5789d229037ad840
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index e2b6efafdd8d0..7bb197df5585b 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -864,7 +865,10 @@ int spi_nor_read_sr1_and_sr2(struct spi_nor *nor, u8 *sr)
> if (ret)
> return ret;
>
> - return spi_nor_read_sr2(nor, &sr[1]);
> + if (nor->params->opcodes.read_sr2)
> + ret = spi_nor_read_sr2(nor, &sr[1]);
> +
> + return ret;
> }
[Severity: High]
Does this code leave sr[1] uninitialized when read_sr2 is unsupported?
In spi_nor_write_sr1_and_sr2_and_check(), an uninitialized u8 tmp[2] is
passed to spi_nor_read_sr1_and_sr2():
drivers/mtd/spi-nor/core.c:spi_nor_write_sr1_and_sr2_and_check() {
u8 tmp[2];
...
ret = spi_nor_read_sr1_and_sr2(nor, tmp);
if (ret)
return ret;
if (sr[0] != tmp[0] || sr[1] != tmp[1])
return -EIO;
...
}
For chips without SR2, tmp[1] remains uninitialized stack garbage and the
comparison sr[1] != tmp[1] can evaluate to true, returning a spurious -EIO
error. This causes quad-enable and device probing to fail for the exact
flashes the patch is attempting to fix.
Also, does this affect spi_nor_otp_lock_sr2()?
drivers/mtd/spi-nor/otp.c:spi_nor_otp_lock_sr2() {
u8 sr[2];
...
ret = spi_nor_read_sr1_and_sr2(nor, sr);
if (ret)
return ret;
/* no need to write the register if region is already locked */
if (sr[1] & lock_bit)
...
}
Here, sr[1] contains garbage, which is evaluated in the lock condition
check and potentially modified and written back to the device.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260911-perso-fix-spi-nor-qe-mxic-v2-1-70c324e9f30e@bootlin.com?part=1
More information about the linux-mtd
mailing list