{"id":"CVE-2026-80975","summary":"mfd: qnap-mcu: keep the reply buffer alive past a command timeout","details":"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_BUFFER_SIZE];\n\t...\n\treply-\u003edata = rx;\n\treply-\u003elength = 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-\u003edata 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-\u003edata or reply-\u003elength on the\ntimeout path. Doing so races with qnap_mcu_receive_buf(), which reads both\nafter its\n\n\tif (!reply-\u003elength)\n\t\treturn size;\n\ncheck: clearing reply-\u003edata gives a NULL dereference, and clearing\nreply-\u003elength alone removes the reply-\u003ereceived == reply-\u003elength 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-\u003elength, which qnap_mcu_exec() has already checked against\nsizeof(mcu-\u003erx).","modified":"2026-09-13T03:47:01.564209422Z","published":"2026-09-11T19:42:37.086Z","database_specific":{"cna_assigner":"Linux","osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/80xxx/CVE-2026-80975.json"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/0b6680e306397097a97767447368221fac753809"},{"type":"WEB","url":"https://git.kernel.org/stable/c/47504742cea7878ebd1bf1491bbed923df6b90b1"},{"type":"WEB","url":"https://git.kernel.org/stable/c/8391ee06d08845a0a165b5fe679ba326915166b2"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/80xxx/CVE-2026-80975.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80975"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"998f70d1806bb718a7565f350283e4a79c8cbb4b"},{"fixed":"0b6680e306397097a97767447368221fac753809"},{"fixed":"8391ee06d08845a0a165b5fe679ba326915166b2"},{"fixed":"47504742cea7878ebd1bf1491bbed923df6b90b1"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-80975.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"6.14.0"},{"fixed":"6.18.51"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.19.0"},{"fixed":"7.2.4"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-80975.json"}}],"schema_version":"1.9.0"}