CVE-2026-80975

mfd: qnap-mcu: keep the reply buffer alive past a command timeout

Published Sep 11, 2026 CVSS 3.1 · 7.8 High EPSS < 1% KEV · Not listed

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:

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).

Analysis

Technical impact

The qnap_mcu driver in the Linux kernel allocates a small on‑stack buffer for replies from the QNAP MCU. On command timeout the driver returns while the buffer is still pointed to, and a later or unsolicited reply can write into that now‑freed stack frame. This race allows an attacker who can inject a delayed response to corrupt the stack, potentially causing a crash or enabling arbitrary code execution. The weakness is a classic example of uncontrolled write to a stale buffer, corresponding to CWE-562.

Affected Systems

The affected product is the Linux kernel’s qnap_mcu driver, used in QNAP devices that expose the MCU interface over a serial device. All kernel versions prior to the patch that moved the receive buffer into the driver’s allocated structure are vulnerable. The driver appears in all Linux kernel releases, so any distribution shipping these kernels with the driver enabled may be impacted until the patch is applied.

Risk and Exploitability

The CVSS base score is 7.8, indicating a high severity. The EPSS score is less than 1%, suggesting a very low likelihood of exploitation. Because the vulnerability is not listed in the CISA KEV catalog, the vulnerability is unlikely to be currently exploited in the wild. The risk remains that an attacker with control over the serial interface to the QNAP MCU could trigger the race condition to corrupt the stack, potentially leading to a crash or arbitrary code execution if the system is vulnerable.

Affected Products

Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).

Vendor Product Default status Versions

Linux

unaffected

Version	Status	Constraints
`998f70d1806bb718a7565f350283e4a79c8cbb4b`	affected	< 0b6680e306397097a97767447368221fac753809
`998f70d1806bb718a7565f350283e4a79c8cbb4b`	affected	< 8391ee06d08845a0a165b5fe679ba326915166b2
`998f70d1806bb718a7565f350283e4a79c8cbb4b`	affected	< 47504742cea7878ebd1bf1491bbed923df6b90b1

Linux

affected

Version	Status	Constraints
`6.14`	affected	—
`0`	unaffected	< 6.14
`6.18.51`	unaffected	≤ 6.18.*
`7.2.4`	unaffected	≤ 7.2.*
`7.3`	unaffected	≤ *

No data.

Vendor Product Versions

Linux

Linux Kernel

Version	Status	Scheme	Platform
`[998f70d1806bb718a7565f350283e4a79c8cbb4b,0b6680e306397097a97767447368221fac753809)`	affected	code_commit	—
`[998f70d1806bb718a7565f350283e4a79c8cbb4b,8391ee06d08845a0a165b5fe679ba326915166b2)`	affected	code_commit	—
`[998f70d1806bb718a7565f350283e4a79c8cbb4b,47504742cea7878ebd1bf1491bbed923df6b90b1)`	affected	code_commit	—

Linux

Linux Kernel

Version	Status	Scheme	Platform
`6.14`	affected	generic	—
`[0,6.14)`	unaffected	generic	—
`[6.18.51,6.19.0)`	unaffected	semver	—
`[7.2.4,7.3.0)`	unaffected	semver	—
`[7.3-rc1,*]`	unaffected	generic	—

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

Apply a kernel update that includes the qnap_mcu driver fix.
Disable the qnap_mcu driver if it is not required.
Restrict access to the QNAP MCU serial device to trusted users or processes, ensuring no untrusted code can send malicious commands.

Generated by OpenCVE AI on September 21, 2026 at 02:22 UTC.

Tracking

Advisories

Source	ID	Title
Ubuntu USN	USN-9019-1	Linux kernel (Azure) vulnerabilities
Ubuntu USN	USN-9020-1	Linux kernel vulnerabilities

Metrics

No CVSS v4.0

Attack Vector Local

Attack Complexity Low

Privileges Required Low

Scope Unchanged

Confidentiality Impact High

Integrity Impact High

Availability Impact High

User Interaction None

No CVSS v3.0

No CVSS v2

This CVE is not in the KEV list.

Exploit prediction score: < 1% (0.173% probability within 30 days)

Key SSVC decision points have not yet been added.

References

Link	Providers
https://git.kernel.org/stable/c/0b6680e306397097a97767447368221fac753809
https://git.kernel.org/stable/c/47504742cea7878ebd1bf1491bbed923df6b90b1
https://git.kernel.org/stable/c/8391ee06d08845a0a165b5fe679ba326915166b2
https://nvd.nist.gov/vuln/detail/CVE-2026-80975
https://www.cve.org/CVERecord?id=CVE-2026-80975

History

Sep 13, 2026 6:45 AM Scoring metrics updated View changes

Type	Values Removed	Values Added
Metrics	cvssV3_1 `{'score': 5.7, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:H'}`	cvssV3_1 `{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}`

Sep 12, 2026 12:15 AM Weaknesses updated. Added references. Scoring metrics updated View changes

Type	Values Removed	Values Added
Weaknesses		CWE-562
References		https://nvd.nist.gov/vuln/detail/CVE-2026-80975 https://www.cve.org/CVERecord?id=CVE-2026-80975
Metrics	threat_severity `None`	cvssV3_1 `{'score': 5.7, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:H'}` threat_severity `Moderate`

Sep 11, 2026 11:45 PM Description updated. Title updated. First appearance in the feed. Affected versions updated. Affected vendors updated. Added references View changes

Type	Values Removed	Values Added
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: 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).
Title		mfd: qnap-mcu: keep the reply buffer alive past a command timeout
First Time appeared		Linux Linux linux Kernel
CPEs		cpe:2.3:o:linux:linux_kernel::::::::
Vendors & Products		Linux Linux linux Kernel
References		https://git.kernel.org/stable/c/0b6680e306397097a97767447368221fac753809 https://git.kernel.org/stable/c/47504742cea7878ebd1bf1491bbed923df6b90b1 https://git.kernel.org/stable/c/8391ee06d08845a0a165b5fe679ba326915166b2