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).
Published: 2026-09-11
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: Memory Corruption
Action: Apply Patch
AI Analysis

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.

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

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

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sun, 13 Sep 2026 06:45:00 +0000

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

Sat, 12 Sep 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-562
References
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

Fri, 11 Sep 2026 23:45:00 +0000

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

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-13T06:28:39.317Z

Reserved: 2026-08-26T14:34:25.810Z

Link: CVE-2026-80975

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-11T20:19:03.763

Modified: 2026-09-13T07:17:04.190

Link: CVE-2026-80975

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-09-11T19:42:37Z

Links: CVE-2026-80975 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-09-21T02:30:08Z

Weaknesses
  • CWE-562

    Return of Stack Variable Address