CVE-2026-80712 in Linux
Summary
by MITRE • 08/28/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified in the Linux kernel SPI NAND driver for Qualcomm platforms represents a critical timing error within the command execution sequence, specifically affecting how feature configuration registers are programmed on SPINAND devices. The root cause lies in the asynchronous nature of the hardware controller's operation relative to software state management. When the function qcom_spi_send_cmdaddr is invoked, it programs the NAND_FLASH_CMD and NAND_EXEC_CMD registers and immediately submits descriptors that trigger the controller to execute the command without delay. However, for operations requiring a SET_FEATURE payload, such as configuring specific chip behaviors or enabling modes like One-Time Programmable memory access, the intended feature value was not included in this initial submission. Instead, qcom_spi_io_op placed the configuration data into the NAND_FLASH_FEATURES register only after the command had already been submitted and executed by the hardware controller. This architectural mismatch results in an off-by-one error where the chip is programmed with whatever stale or residual data happened to reside in the feature register from a previous operation, while the newly intended value is applied only during the subsequent SET_FEATURE transaction.
This timing discrepancy manifests as a persistent state desynchronization between the driver's intent and the physical NAND flash device status. In practical terms, any attempt to write a specific configuration byte results in that change being ignored for one cycle; instead, the previous pending value takes effect. For example, writing 0x40 to a configuration register might leave the chip at state 0x00 if it previously held zero, and only when another operation follows does the 0x40 take hold. While this behavior is generally benign for simple read operations or non-critical configurations, it becomes catastrophic when applied to mode-switching commands that alter fundamental device behaviors. The issue remained latent until kernel version 6.18 introduced support for SPI-NAND One-Time Programmable memory regions and added specific OTP entries for ESMT chips. This new functionality relies heavily on precise state transitions between normal array mode and OTP access mode, exposing the underlying race condition in the driver's command sequencing logic.
The operational impact of this vulnerability is severe, particularly on devices utilizing ESMT F50L1G41LB NAND flash paired with IPQ5018 SoCs, such as the TP-Link Archer AX55 v1 router. The spinand_otp_rw function attempts to enable OTP mode for reading or writing, perform the operation, and then disable OTP mode to return the device to normal array access. Due to the off-by-one error, when the driver issues a command to disable OTP mode, it actually applies the value from the preceding enable command. Consequently, the CFG_OTP_ENABLE bit remains set in the chip's configuration register even after the software believes it has been cleared. This leaves the flash device permanently stuck in OTP access mode. In this state, all subsequent array read operations return data exclusively from the small OTP region rather than the main storage area, causing upper-layer filesystem drivers like UBI to perceive the device as empty or corrupted because they cannot locate valid superblocks or metadata structures.
Furthermore, the persistence of OTP mode leads to a complete loss of write capability for the main flash array. The OTP area is inherently write-protected by design once configured, and its activation prevents normal program/erase cycles on the primary storage space. As a result, any attempt to write data fails with an I/O error code (-EIO). On embedded systems where the root filesystem or critical boot partitions reside on this flash chip, this condition renders the device unbootable and effectively bricks it until hardware-level intervention is performed. The vulnerability essentially creates a denial of service against the storage subsystem by locking out normal access patterns through incorrect state management during mode transitions.
From a standards perspective, this flaw aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization of Accessed Resources, as it involves a race between command submission and data preparation within an asynchronous hardware interface. It also relates to CWE-841, Improper Enforcement of Behavioral Workflow, because the driver fails to enforce the correct sequence of operations required by the SPINAND specification before executing commands that depend on specific register states. In terms of MITRE ATT&CK mapping for embedded systems, this could be categorized under T1562.001, Impair Defense: Disable or Modify Tools, if an attacker were able to exploit similar timing issues in other drivers to disable security features, though here it is primarily a reliability and availability issue rather than a direct exploitation vector for privilege escalation.
The remediation involves restructuring the qcom_spi_io_op function to ensure that feature values are written into the NAND_FLASH_FEATURES register prior to submitting the command descriptors via qcom_spi_send_cmdaddr. By placing the configuration data in the correct hardware buffer before triggering execution, the driver guarantees that the intended value is applied immediately during the current transaction rather than being delayed until a future operation. Additionally, the fix addresses a secondary memory safety issue where the previous code dereferenced a four-byte pointer on a one-byte scratch buffer, which posed potential risks of out-of-bounds reads or writes depending on compiler optimizations and stack layout. Correcting this ensures that only the necessary bytes are copied during feature configuration operations.
Verification of the patch confirms that flash contents read back bit-identical to known-good dumps taken under vendor firmware, validating that the state synchronization is restored across all partitions. Writes now succeed without error codes, restoring full functionality to the storage subsystem and allowing devices like the TP-Link Archer AX55 v1 to boot correctly after updates involving SPI-NAND OTP support. This case highlights the critical importance of verifying hardware-software timing constraints in kernel drivers for embedded systems, particularly when dealing with asynchronous command queues and stateful peripheral configurations that lack automatic synchronization mechanisms.