---
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'
---

## Overview

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:

	unsigned char rx[QNAP_MCU_RX_BUFFER_SIZE];
	...
	reply->data = rx;
	reply->length = 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->data 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->data or reply->length on the
timeout path. Doing so races with qnap_mcu_receive_buf(), which reads both
after its

	if (!reply->length)
		return size;

check: clearing reply->data gives a NULL dereference, and clearing
reply->length alone removes the reply->received == reply->length 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->length, which qnap_mcu_exec() has already checked against
sizeof(mcu->rx).

## Affected

- `Linux >= 998f70d1806bb718a7565f350283e4a79c8cbb4b < 0b6680e306397097a97767447368221fac753809`
- `Linux >= 998f70d1806bb718a7565f350283e4a79c8cbb4b < 8391ee06d08845a0a165b5fe679ba326915166b2`
- `Linux >= 998f70d1806bb718a7565f350283e4a79c8cbb4b < 47504742cea7878ebd1bf1491bbed923df6b90b1`
- `Linux 6.14`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.

## Vendor advisories

- **Red Hat VEX** · Moderate · updated 2026-09-14 · [vex](https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-80975.json)