{"id":"CVE-2026-80975","title":"mfd: qnap-mcu: keep the reply buffer alive past a command timeout","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmfd: qnap-mcu: keep the reply buffer alive past a command timeout\n\nqnap_mcu_exec() publishes an on-stack buffer to the receive path:\n\n\tunsigned char rx[QNAP_MCU_RX_BUFF…","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","cvssSource":"cna","cwe":["CWE-562"],"vendor":"Linux","product":"Linux","affected":["Linux >= 998f70d1806bb718a7565f350283e4a79c8cbb4b < 0b6680e306397097a97767447368221fac753809","Linux >= 998f70d1806bb718a7565f350283e4a79c8cbb4b < 8391ee06d08845a0a165b5fe679ba326915166b2","Linux >= 998f70d1806bb718a7565f350283e4a79c8cbb4b < 47504742cea7878ebd1bf1491bbed923df6b90b1","Linux 6.14"],"published":"2026-09-11","updated":"2026-10-19","sourceUpdated":"2026-10-19T08:45:59.772Z","source":"CVEORG","sourceUrl":"https://www.cve.org/CVERecord?id=CVE-2026-80975","references":[{"url":"https://git.kernel.org/stable/c/0b6680e306397097a97767447368221fac753809"},{"url":"https://git.kernel.org/stable/c/8391ee06d08845a0a165b5fe679ba326915166b2"},{"url":"https://git.kernel.org/stable/c/47504742cea7878ebd1bf1491bbed923df6b90b1"},{"url":"https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-80975.json"},{"url":"https://access.redhat.com/security/cve/CVE-2026-80975"},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2532227"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-80975"},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80975"},{"url":"https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-80975.mbox"}],"tags":["cve.org","csaf","vex","red-hat","score-dispute"],"epss":0.00173,"epssPercentile":0.0672,"scores":{"cna":7.8,"vendor":5.5},"ingestedAt":"2026-09-14T15:23:07.476Z","slug":"CVE-2026-80975","body":"## Overview\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmfd: qnap-mcu: keep the reply buffer alive past a command timeout\n\nqnap_mcu_exec() publishes an on-stack buffer to the receive path:\n\n\tunsigned char rx[QNAP_MCU_RX_BUFFER_SIZE];\n\t...\n\treply->data = rx;\n\treply->length = length;\n\nand qnap_mcu_receive_buf() writes into it from the serdev receive path,\nwhich runs out of flush_to_ldisc() and is not serialized against\nqnap_mcu_exec() at all. bus_lock cannot cover it, because qnap_mcu_exec()\nholds that mutex across wait_for_completion_timeout().\n\nOn a timeout qnap_mcu_exec() returns with reply->data still pointing at\nits own frame. A reply that arrives late, or an unsolicited message from\nthe MCU, is then written into a stack frame that has been left, corrupting\nwhatever runs next on that stack. The same applies when qnap_mcu_write()\nfails, since that path returns without touching the reply state either.\n\nMove the receive buffer into struct qnap_mcu. It is 37 bytes and the\nstructure is devm_kzalloc()ed, so it lives as long as the driver, and a\nlate write lands in memory that is still valid and is reinitialized by the\nnext command. bus_lock keeps commands from sharing it.\n\nThis deliberately does not clear reply->data or reply->length on the\ntimeout path. Doing so races with qnap_mcu_receive_buf(), which reads both\nafter its\n\n\tif (!reply->length)\n\t\treturn size;\n\ncheck: clearing reply->data gives a NULL dereference, and clearing\nreply->length alone removes the reply->received == reply->length exit\ncondition, so the copy loop runs until the uart chunk is consumed and\noverruns the buffer. Leaving both set keeps the write bounded by\nreply->length, which qnap_mcu_exec() has already checked against\nsizeof(mcu->rx).\n\n## Affected\n\n- `Linux >= 998f70d1806bb718a7565f350283e4a79c8cbb4b < 0b6680e306397097a97767447368221fac753809`\n- `Linux >= 998f70d1806bb718a7565f350283e4a79c8cbb4b < 8391ee06d08845a0a165b5fe679ba326915166b2`\n- `Linux >= 998f70d1806bb718a7565f350283e4a79c8cbb4b < 47504742cea7878ebd1bf1491bbed923df6b90b1`\n- `Linux 6.14`\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.\n\n## Vendor advisories\n\n- **Red Hat VEX** · Moderate · updated 2026-09-14 · [vex](https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-80975.json)","depth":"twilight","depthScore":43,"depthScoreParts":{"impact":42.9,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[{"seq":224797,"id":"CVE-2026-80975","ts":1792401548743,"field":"cvss","old":"5.5","new":"7.8"},{"seq":224796,"id":"CVE-2026-80975","ts":1792401548743,"field":"severity","old":"medium","new":"high"},{"seq":204192,"id":"CVE-2026-80975","ts":1789490239019,"field":"cvss","old":"5.7","new":"5.5"},{"seq":202939,"id":"CVE-2026-80975","ts":1789403733032,"field":"cvss","old":"7.8","new":"5.7"},{"seq":202938,"id":"CVE-2026-80975","ts":1789403733032,"field":"severity","old":"high","new":"medium"},{"seq":183606,"id":"CVE-2026-80975","ts":1789356676077,"field":"cvss","old":"7.8","new":"5.7"},{"seq":183605,"id":"CVE-2026-80975","ts":1789356676077,"field":"severity","old":"high","new":"medium"},{"seq":153154,"id":"CVE-2026-80975","ts":1789285349323,"field":"cvss","old":null,"new":"7.8"},{"seq":153153,"id":"CVE-2026-80975","ts":1789285349323,"field":"severity","old":"none","new":"high"},{"seq":147516,"id":"CVE-2026-80975","ts":1789270211214,"field":"cvss","old":null,"new":"5.7"},{"seq":147515,"id":"CVE-2026-80975","ts":1789270211214,"field":"severity","old":"none","new":"medium"},{"seq":109272,"id":"CVE-2026-80975","ts":1789183731228,"field":"cvss","old":null,"new":"5.7"},{"seq":109271,"id":"CVE-2026-80975","ts":1789183731228,"field":"severity","old":"none","new":"medium"}]}