{
  "cveId": "CVE-2026-80975",
  "url": "https://patchblox.com/security/cve/CVE-2026-80975",
  "summary": "CVE-2026-80975 is fixed in linux on 1 platform by DEBIAN-CVE-2026-80975 (version 7.2.6-1), released September 23, 2026. It is not reported as exploited. Patch Radar priority: High.",
  "title": "linux: In the Linux kernel, the following vulnerability has been resolved:  mfd: qnap-mcu: keep the reply buffer alive past...",
  "description": "In the Linux kernel, the following vulnerability has been resolved:  mfd: qnap-mcu: keep the reply buffer alive past a command timeout  qnap_mcu_exec() publishes an on-stack buffer to the receive path:  \tunsigned char rx[QNAP_MCU_RX_BUFFER_SIZE]; \t... \treply-\u003Edata = rx; \treply-\u003Elength = length;  and qnap_mcu_receive_buf() writes into it from the serdev receive path, which runs out of flush_to_ldisc() and is not serialized against qnap_mcu_exec() at all. bus_lock cannot cover it, because qnap_mcu_exec() holds that mutex across wait_for_completion_timeout().  On a timeout qnap_mcu_exec() returns with reply-\u003Edata still pointing at its own frame. A reply that arrives late, or an unsolicited message from the MCU, is then written into a stack frame that has been left, corrupting whatever runs next on that stack. The same applies when qnap_mcu_write() fails, since that path returns without touching the reply state either.  Move the receive buffer into struct qnap_mcu. It is 37 bytes and the structure is devm_kzalloc()ed, so it lives as long as the driver, and a late write lands in memory that is still valid and is reinitialized by the next command. bus_lock keeps commands from sharing it.  This deliberately does not clear reply-\u003Edata or reply-\u003Elength on the timeout path. Doing so races with qnap_mcu_receive_buf(), which reads both after its  \tif (!reply-\u003Elength) \t\treturn size;  check: clearing reply-\u003Edata gives a NULL dereference, and clearing reply-\u003Elength alone removes the reply-\u003Ereceived == reply-\u003Elength exit condition, so the copy loop runs until the uart chunk is consumed and overruns the buffer. Leaving both set keeps the write bounded by reply-\u003Elength, which qnap_mcu_exec() has already checked against sizeof(mcu-\u003Erx).",
  "published": "2026-09-11T20:19:03Z",
  "severity": "high",
  "cvss": 7.8,
  "cvssVector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
  "epss": 0.00173,
  "epssPercentile": 0.06812,
  "priority": "High",
  "priorityTier": 3,
  "exploited": false,
  "vendorExploited": false,
  "disclosed": false,
  "fixes": [
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 14",
      "fixedVersion": "7.2.6-1",
      "fix": "DEBIAN-CVE-2026-80975",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2026-80975",
      "released": "2026-09-23T19:19:02Z"
    }
  ],
  "noFixYet": [],
  "dataAsOf": "2026-11-08T00:53:09Z",
  "attribution": {
    "text": "Data: Patchblox Patch Radar",
    "url": "https://patchblox.com/security/patch-radar",
    "terms": "https://patchblox.com/security/patch-radar/use-the-data"
  }
}