{
  "cveId": "CVE-2026-80712",
  "url": "https://patchblox.com/security/cve/CVE-2026-80712",
  "summary": "CVE-2026-80712 is fixed in linux on 1 platform by DEBIAN-CVE-2026-80712 (version 7.1.8-1), released August 29, 2026. It is not reported as exploited. Patch Radar priority: High.",
  "title": "linux: In the Linux kernel, the following vulnerability has been resolved:  spi: spi-qpic-snand: write the feature value bef...",
  "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 \u0022disable\u0022 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-\u003Escratchbuf).  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.",
  "published": "2026-08-28T08:16:56Z",
  "severity": "high",
  "cvss": 8.4,
  "cvssVector": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
  "epss": 0.00194,
  "epssPercentile": 0.09096,
  "priority": "High",
  "priorityTier": 3,
  "exploited": false,
  "vendorExploited": false,
  "disclosed": false,
  "fixes": [
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 14",
      "fixedVersion": "7.1.8-1",
      "fix": "DEBIAN-CVE-2026-80712",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2026-80712",
      "released": "2026-08-29T00:46:20Z"
    }
  ],
  "noFixYet": [],
  "dataAsOf": "2026-11-08T19:12:23Z",
  "attribution": {
    "text": "Data: Patchblox Patch Radar",
    "url": "https://patchblox.com/security/patch-radar",
    "terms": "https://patchblox.com/security/patch-radar/use-the-data"
  }
}