Look up another CVE · open CVE-2026-80975 in the interactive tracker
CVE-2026-80975
mfd: qnap-mcu: keep the reply buffer alive past a command timeout
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem drivers/mfd. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-80975 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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).
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/mfd/qnap-mcu.c
- What this is
- QNAP MCU DRIVERMAINTAINERS section matched on drivers/mfd/qnap-mcu.c · Maintained
- Kernel module
- qnap_mcu
Check it on the machine
grep -w CONFIG_MFD_QNAP_MCU /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w qnap_mcuPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed. The build rule could not be established for 2 releases, so nothing is claimed about those.
- bookworm, trixie?
- forky, sidMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt-amd64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- ?
- not established - no Makefile entry for the affected file
- M
- a module where it is built at all; some flavours do not build it
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switch
- CONFIG_MFD_QNAP_MCU
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 6.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/mfd
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.14 | 6.18.51 | 0b6680e30639 |
| 6.14 | 7.2.4 | 8391ee06d088 |
| 6.14 | 7.3 | 47504742cea7 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The bug is reached only through local qnap_mcu_exec() calls from hwmon/nvmem/LED/input/thermal sysfs on QNAP NAS devices whose MCU is a soldered UART serdev child, not a network protocol or a user-pluggable USB device, so the vector is Local rather than Physical.
- AC:LAttack complexity, low
- This is use-after-return of an on-stack RX buffer published to qnap_mcu_receive_buf(), which runs from flush_to_ldisc() with no lock shared with qnap_mcu_exec(); an attacker issues commands via sysfs, retries at will, and after the 500 ms timeout reply->data still points at their kernel stack so a late or unsolicited MCU chunk writes into that frame.
- PR:LPrivileges required, low
- Fan/temp hwmon attributes are mode 0444 and pwm is 0644, and the EEPROM nvmem is registered with root_only=false (0444), so any unprivileged local user can invoke qnap_mcu_exec() by reading those sysfs files without capabilities or init-namespace root.
- UI:NUser interaction, none
- Exploitation uses the attacker’s own reads of already-present hwmon and nvmem sysfs; no victim must mount a filesystem, plug in hardware, or otherwise act, and thermal cooling plus input polling can also enter the same path automatically.
- S:UScope, unchanged
- The use-after-return corrupts the kernel stack of the task or kworker that called qnap_mcu_exec() on the same host; it does not cross a VM, IOMMU, or sandbox boundary into a separate security authority.
- C:HConfidentiality impact, high
- A late UART write of up to 37 bytes into a returned kernel stack frame is use-after-return memory corruption; the attacker can groom that stack with a follow-up syscall so the overwrite becomes a kernel read primitive, which per UAF guidance is High confidentiality impact.
- I:HIntegrity impact, high
- The same write into the abandoned stack can smash return addresses, saved registers, and pointers of the next function on that stack, including after attacker-controlled syscall grooming, yielding control-flow hijack; use-after-return stack corruption is High integrity impact.
- A:HAvailability impact, high
- Writing MCU UART bytes into a kernel stack frame that has already been left corrupts in-use stack state and causes an oops or panic even when not turned into a full exploit, fully denying availability.