Description

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

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.4",
  "pubDate": "2026-08-28T08:16:56.850Z",
  "pubdate": "2026-08-28T08:16:56.850Z",
  "executiveSummary": "A logic flaw in the Linux kernel's spi-qpic-snand driver causes a synchronization error during SET_FEATURE operations on SPI-NAND flash devices.\nThe vulnerability occurs because the feature value is written to the NAND_FLASH_FEATURES register after the execution command is issued to the controller, resulting in an off-by-one operation error.\nThis leads to incorrect register configuration, most notably trapping devices in OTP (One-Time Programmable) mode after initialization attempts.\nImpact includes system-wide unbootability, inability to access flash partitions (UBI), and potential write failures resulting in -EIO errors.\nThe flaw affects devices utilizing the Qualcomm SPI-NAND controller, such as the IPQ5018 SoC, and was exacerbated by changes in kernel version 6.18 regarding OTP support.\nNo specific attacker capability is required to trigger this as it is a kernel-level driver defect, though malicious exploitation could leverage this persistence mechanism to render a device permanently unusable or cause data corruption.",
  "technicalDetails": "The root cause of the vulnerability lies in the improper sequence of register programming within qcom_spi_send_cmdaddr() and qcom_spi_io_op(). In the original implementation, the controller is instructed to execute a SPINAND_SET_FEATURE command via NAND_EXEC_CMD before the actual feature value is written to the NAND_FLASH_FEATURES register.\nBecause the controller executes the command immediately upon receiving the submission, the SPI-NAND chip is programmed with the stale value previously stored in NAND_FLASH_FEATURES. The intended value is only written to the register during a subsequent submission, creating a persistent off-by-one latency in register state updates.\nThe attack flow/operational failure occurs as follows: When the driver attempts to enable or disable specific modes (such as OTP mode), the hardware effectively ignores the immediate request and applies the previous state. For example, when mtd_otp_nvmem_add() initiates OTP read cycles, the driver disables OTP mode at the end of the operation. Due to the race condition, the 'disable' command actually applies the previous value, and the 'enable' value is only committed when the next operation occurs. Consequently, the chip remains stuck in OTP mode.\nPost-exploitation/Impact: Once the chip is trapped in OTP mode, all subsequent array read operations return the OTP area instead of the main flash array. This causes UBI (Unsorted Block Images) to report the device as empty. Furthermore, writes to the flash are rejected by the hardware because the OTP area is inherently write-protected, leading to -EIO errors.\nAdditional technical debt identified includes an improper memory access pattern: the code previously dereferenced a 4-byte pointer against a 1-byte buffer (spinand->scratchbuf). This, while not the primary cause of the register race, introduced potential memory corruption risks by reading past the allocated buffer bounds.\nAffected component: spi-qpic-snand driver in the Linux kernel. The issue affects hardware implementations where command execution is strictly tied to the initial descriptor submission of the NAND controller, specifically noted on IPQ5018 platforms."
}