CVE-2026-80975

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