CVE-2026-80712
Gravedad:
Pendiente de análisis
Tipo:
No Disponible / Otro tipo
Fecha de publicación:
28/08/2026
Última modificación:
28/08/2026
Descripción
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
spi: spi-qpic-snand: write the feature value before executing SET_FEATURE<br />
<br />
qcom_spi_send_cmdaddr() programs NAND_FLASH_CMD/NAND_EXEC_CMD and submits<br />
the descriptors, which makes the controller execute the command<br />
immediately. For SPINAND_SET_FEATURE the value to be written is only<br />
placed into NAND_FLASH_FEATURES afterwards, by qcom_spi_io_op(), in a<br />
second submission - so the chip is programmed with whatever that register<br />
happened to hold from a previous operation, and the intended value is only<br />
applied by the *next* SET_FEATURE.<br />
<br />
Measured on a TP-Link Archer AX55 v1 (IPQ5018, ESMT F50L1G41LB): writing<br />
0x40 to the configuration register (0xb0) leaves the chip at 0x00, and the<br />
subsequent write of 0x00 leaves it at 0x40 - every write lands one<br />
operation late.<br />
<br />
This stayed unnoticed until v6.18 added SPI-NAND OTP support together<br />
with OTP entries for ESMT chips. spinand_otp_rw() enables OTP mode,<br />
reads, and disables it again, and mtd_otp_nvmem_add() does this during<br />
MTD registration. With the off-by-one, the "disable" write actually<br />
applies the previously requested value, so CFG_OTP_ENABLE ends up set:<br />
the chip stays in OTP mode, every subsequent array read returns the OTP<br />
area instead of the array (UBI reports an empty device) and all writes<br />
fail with -EIO because the OTP area is write protected. On this board<br />
that makes the whole flash unusable and the device unbootable.<br />
<br />
Write the feature value into NAND_FLASH_FEATURES as part of the same<br />
transaction, before NAND_EXEC_CMD. While at it, copy only the bytes the<br />
operation actually carries - the previous code dereferenced a 4-byte<br />
pointer on a one-byte buffer (spinand->scratchbuf).<br />
<br />
With this patch the flash contents read back bit-identical to a<br />
known-good dump of the same board taken under the vendor firmware<br />
(md5-verified across partitions), and writes work.



