<Vulnerability name="CVE-2026-80712">
    <DocumentDistribution xml:lang="en">Copyright © 2012 Red Hat, Inc. All rights reserved.</DocumentDistribution>
    <ThreatSeverity>Moderate</ThreatSeverity>
    <PublicDate>2026-08-28T00:00:00</PublicDate>
    <Bugzilla id="2525393" url="https://bugzilla.redhat.com/show_bug.cgi?id=2525393" xml:lang="en:us">
kernel: spi: spi-qpic-snand: write the feature value before executing SET_FEATURE
    </Bugzilla>
    <CVSS3 status="draft">
        <CVSS3BaseScore>5.5</CVSS3BaseScore>
        <CVSS3ScoringVector>CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</CVSS3ScoringVector>
    </CVSS3>
    <CWE>CWE-805</CWE>
    <Details xml:lang="en:us" source="Mitre">
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-&gt;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.
    </Details>
    <Details xml:lang="en:us" source="Red Hat">
A flaw was found in the Linux kernel's `spi-qpic-snand` driver. This vulnerability arises from an incorrect timing issue where the `SET_FEATURE` command for SPI-NAND flash devices is executed before the intended feature value is properly written. Consequently, the device is programmed with an outdated value, and the correct setting is only applied during a subsequent operation. This 'off-by-one' error can lead to critical system instability, specifically by causing the flash memory to remain in One-Time Programmable (OTP) mode if it was enabled. This renders the flash unusable, preventing data access and potentially making the device unbootable.
    </Details>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:10">
        <ProductName>Red Hat Enterprise Linux 10</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:6">
        <ProductName>Red Hat Enterprise Linux 6</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:7">
        <ProductName>Red Hat Enterprise Linux 7</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:7">
        <ProductName>Red Hat Enterprise Linux 7</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel-rt</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:8">
        <ProductName>Red Hat Enterprise Linux 8</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:8">
        <ProductName>Red Hat Enterprise Linux 8</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel-rt</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:9">
        <ProductName>Red Hat Enterprise Linux 9</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:9">
        <ProductName>Red Hat Enterprise Linux 9</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel-rt</PackageName>
    </PackageState>
    <References xml:lang="en:us">
https://www.cve.org/CVERecord?id=CVE-2026-80712
https://nvd.nist.gov/vuln/detail/CVE-2026-80712
https://lore.kernel.org/linux-cve-announce/2026082808-CVE-2026-80712-e74e@gregkh/T
    </References>
</Vulnerability>