CVE-2026-80975

W jądrze Linuksa usunięto następującą lukę:

mfd: qnap-mcu: utrzymuje bufor odpowiedzi przy życiu po przekroczeniu limitu czasu polecenia

qnap_mcu_exec() publikuje bufor na stosie w ścieżce odbiorczej:

znak bez znaku rx[QNAP_MCU_RX_BUFFER_SIZE];
...
odpowiedź->dane = rx;
odpowiedź->długość = długość;

i qnap_mcu_receive_buf() zapisuje do niego ze ścieżki odbiorczej serdev,
której kończy się funkcja Flush_to_ldisc() i nie jest ona serializowana
qnap_mcu_exec() w ogóle. bus_lock nie może tego zasłonić, ponieważ qnap_mcu_exec()
przechowuje ten muteks w funkcji wait_for_completion_timeout().

Po przekroczeniu limitu czasu funkcja qnap_mcu_exec() powraca z odpowiedzią->dane nadal wskazującą
własną ramę. Odpowiedź, która nadeszła z opóźnieniem lub niechciana wiadomość od
MCU, jest następnie zapisywany w pozostawionej ramce stosu, powodując uszkodzenie
cokolwiek będzie dalej działać na tym stosie. To samo dotyczy funkcji qnap_mcu_write()
kończy się niepowodzeniem, ponieważ ścieżka ta powraca bez dotykania stanu odpowiedzi.

Przenieś bufor odbioru do struktury qnap_mcu. Ma 37 bajtów i
struktura jest devm_kzalloc(), więc żyje tak długo, jak sterownik, oraz a
późny zapis ląduje w pamięci, która jest nadal ważna i jest ponownie inicjowana przez
następne polecenie. bus_lock uniemożliwia poleceniom udostępnianie go.

To celowo nie usuwa odpowiedzi->danych ani odpowiedzi->długości w pliku
ścieżka przekroczenia limitu czasu. Spowoduje to wyścig z funkcją qnap_mcu_receive_buf(), która odczytuje oba
po nim

if (!odpowiedź->długość)
rozmiar zwrotu;

sprawdź: wyczyszczenie odpowiedzi->dane daje wyłuskanie NULL i wyczyszczenie
odpowiedź->długość sama usuwa odpowiedź->otrzymano == odpowiedź->długość wyjścia
warunek, więc pętla kopiowania działa do momentu zużycia fragmentu uart i
przekracza bufor. Pozostawienie obu zestawów powoduje, że zapis jest ograniczony przez
odpowiedź->długość, którą qnap_mcu_exec() już sprawdziła
rozmiar(mcu->rx).