CVE-2026-89480
NieznaneStreszczenie
W jądrze Linux w sterowniku nvme-tcp funkcja nvme_tcp_recv_data() kończy żądanie po odebraniu bieżącego PDU C2HData, nie porównując łącznej liczby odebranych bajtów z długością żądaną przez polecenie. Złośliwy kontroler może odpowiedzieć na odczyt 4096 bajtów tylko 512 bajtami, a żądanie zostanie zgłoszone jako zakończone, ujawniając użytkownikowi 3584 bajty starych danych ze strony. Poprawka zlicza odebrane bajty i odmawia zakończenia niepełnego odczytu.
Ocena ryzyka
Ujawnienie starych danych z pamięci jądra (page cache) użytkownikowi przestrzeni użytkownika poprzez niepełny odczyt. Może prowadzić do wycieku informacji wrażliwych.
Rekomendacja
Zaktualizuj jądro Linux do wersji zliczającej odebrane bajty i weryfikującej je przed zakończeniem odczytu. Do czasu aktualizacji rozważ ograniczenie zaufania do kontrolerów NVMe over TCP.
Inne podatności w Linux kernel (nvme-tcp)
Zobacz wszystkie- CVE-2026-89482Nieznane
W jądrze Linux w sterowniku nvme-tcp występuje luka polegająca na tym, że odbiór danych C2HData był weryfikowany wyłącznie na podstawie blk_rq_payload_bytes(), bez sprawdzenia req->data_len. Dla operacji WRITE_ZEROES, która nie ma segmentów fizycznych, ale ma niezerowe blk_rq_bytes(), prowadzi to do kopiowania danych do niezainicjalizowanego iteratora i błędu wild-memory-access (KASAN) w _copy_to_iter().
- CVE-2026-89481Nieznane
W jądrze Linux w sterowniku nvme-tcp funkcja nvme_tcp_handle_r2t() nie sprawdza kierunku żądania, którego dotyczy R2T. Złośliwy kontroler może wysłać R2T dla polecenia READ, a host odpowie, wysyłając bufor docelowy odczytu (zawierający stare dane jądra) do kontrolera. Luka ujawnia pamięć jądra, w tym wskaźniki struct page.
Oryginalny opis (angielski, źródło NVD)
In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: reject a read that transferred too few bytes nvme_tcp_recv_data() completes a request once the current C2HData PDU has been consumed. Nothing compares the total bytes received against the length the command asked for: struct nvme_tcp_request has no receive-side counter, queue->data_remaining is per queue, and blk_mq_end_request() completes for blk_rq_bytes(rq) unconditionally with no residual concept anywhere above. A controller can therefore answer a 4096-byte read with 512 bytes and have it reported as a complete read; user space then gets 4096 bytes of which 3584 are whatever was already in the page. I reproduced that with a test target. Count the bytes received and refuse to complete a successful read whose count does not match, at the two NVME_TCP_F_DATA_SUCCESS paths and in nvme_tcp_process_nvme_cqe(). The success test shifts req->status right by one, because the driver keeps the wire value there and shifts it on completion, so the check must see what the completion path will see. Only REQ_OP_READ is checked, because there the length comes from the sectors the request covers; a passthrough command is built by its submitter, which picks both command and buffer, so the kernel has nothing to compare against.