In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
mfd: qnap-mcu: keep the reply buffer alive past a command timeout<\/p>\n
qnap_mcu_exec() publishes an on-stack buffer to the receive path:<\/p>\n
\tunsigned char rx[QNAP_MCU_RX_BUFFER_SIZE];
\n\t…
\n\treply->data = rx;
\n\treply->length = length;<\/p>\n
and qnap_mcu_receive_buf() writes into it from the serdev receive path,
\nwhich runs out of flush_to_ldisc() and is not serialized against
\nqnap_mcu_exec() at all. bus_lock cannot cover it, because qnap_mcu_exec()
\nholds that mutex across wait_for_completion_timeout().<\/p>\n
On a timeout qnap_mcu_exec() returns with reply->data still pointing at
\nits own frame. A reply that arrives late, or an unsolicited message from
\nthe MCU, is then written into a stack frame that has been left, corrupting
\nwhatever runs next on that stack. The same applies when qnap_mcu_write()
\nfails, since that path returns without touching the reply state either.<\/p>\n
Move the receive buffer into struct qnap_mcu. It is 37 bytes and the
\nstructure is devm_kzalloc()ed, so it lives as long as the driver, and a
\nlate write lands in memory that is still valid and is reinitialized by the
\nnext command. bus_lock keeps commands from sharing it.<\/p>\n
This deliberately does not clear reply->data or reply->length on the
\ntimeout path. Doing so races with qnap_mcu_receive_buf(), which reads both
\nafter its<\/p>\n
\tif (!reply->length)
\n\t\treturn size;<\/p>\n
check: clearing reply->data gives a NULL dereference, and clearing
\nreply->length alone removes the reply->received == reply->length exit
\ncondition, so the copy loop runs until the uart chunk is consumed and
\noverruns the buffer. Leaving both set keeps the write bounded by
\nreply->length, which qnap_mcu_exec() has already checked against
\nsizeof(mcu->rx).<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
mfd: qnap-mcu: keep the reply buffer alive past a command timeout<\/p>\n
qnap_mcu_exec() publishes an on-stack buffer to the receive path<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-21308","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/21308","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=21308"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=21308"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=21308"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}