CVE-2026-89480
UnknownSummary
In the Linux kernel, the nvme-tcp driver's nvme_tcp_recv_data() completes a request once the current C2HData PDU is consumed, without comparing total bytes received against the length the command asked for. A malicious controller can answer a 4096-byte read with 512 bytes and have it reported as complete, exposing 3584 bytes of stale page data to user space. The fix counts received bytes and refuses to complete an incomplete read.
Risk Assessment
Discloses stale kernel memory (page cache) to user space via an incomplete read. Can lead to leakage of sensitive information.
Recommendation
Update the Linux kernel to a version that counts received bytes and verifies them before completing a read. Until patched, consider limiting trust in NVMe over TCP controllers.
Other vulnerabilities in Linux kernel (nvme-tcp)
See all- CVE-2026-89482Unknown
In the Linux kernel, the nvme-tcp driver accepted C2HData based solely on blk_rq_payload_bytes() without also checking req->data_len. For REQ_OP_WRITE_ZEROES, which has no physical segments but a non-zero blk_rq_bytes(), this causes data to be copied into an uninitialized iterator, triggering a KASAN wild-memory-access in _copy_to_iter().
- CVE-2026-89481Unknown
In the Linux kernel, the nvme-tcp driver's nvme_tcp_handle_r2t() does not check the direction of the request the R2T refers to. A malicious controller can send an R2T for a READ and the host will answer it, sending the READ destination buffer (containing stale kernel data) to the controller. This leaks host memory, including struct page pointers.
Original NVD description (English source)
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.