CVE-2026-89480

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.