В ядре Linux устранена следующая уязвимость:
mfd: qnap-mcu: поддерживать буфер ответа в рабочем состоянии после таймаута команды
qnap_mcu_exec() публикует буфер в стеке по пути приема:
беззнаковый символ rx[QNAP_MCU_RX_BUFFER_SIZE];
...
ответ-> данные = rx;
ответ-> длина = длина;
и qnap_mcu_receive_buf() записывает в него данные из пути получения serdev,
который заканчивается flash_to_ldisc() и не сериализуется против
qnap_mcu_exec() вообще. bus_lock не может его закрыть, потому что qnap_mcu_exec()
удерживает этот мьютекс в течение wait_for_completion_timeout(). По истечении времени ожидания qnap_mcu_exec() возвращает ответ->данные, все еще указывающие на
свой каркас. Ответ, пришедший с опозданием, или нежелательное сообщение от
MCU затем записывается в оставшийся кадр стека, повреждая
что бы ни запускалось дальше в этом стеке.
То же самое применимо, когда qnap_mcu_write()
терпит неудачу, поскольку этот путь возвращается, не затрагивая состояние ответа. Переместите буфер приема в структуру qnap_mcu. Это 37 байт и
Структура создана с помощью devm_kzalloc(), поэтому она существует до тех пор, пока работает драйвер, и
поздняя запись попадает в память, которая все еще действительна и повторно инициализируется
следующая команда. bus_lock не позволяет командам делиться им.
Это намеренно не очищает ответ->данные или ответ->длину на
путь тайм-аута. При этом выполняется вызов qnap_mcu_receive_buf(), который считывает оба
после его
if (!reply->длина)
размер возврата;
проверка: очистка ответа->данные дает разыменование NULL и очистка
только ответ->длина удаляет ответ->получено == ответ->длина выход
условие, поэтому цикл копирования выполняется до тех пор, пока фрагмент uart не будет использован и
переполняет буфер. Если оставить оба значения, запись будет ограничена
ответ->длина, которую qnap_mcu_exec() уже проверил
sizeof(mcu->rx).
Показать оригинальное описание (EN)
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).
Характеристики атаки
Последствия
Строка CVSS v3.1