CVE-2026-89480: nvme-tcp: reject a read that transferred too few bytes
In the Linux kernel, the following vulnerability has been resolved:
nvme-tcp: reject a read that transferred too few bytes
nvmetcprecvdata() 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 nvmetcprequest has no receive-side counter, queue->dataremaining is per queue, and blkmqendrequest() completes for blkrqbytes(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 NVMETCPFDATASUCCESS paths and in nvmetcpprocessnvmecqe(). 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 REQOPREAD 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.
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems using the Linux kernel NVMe/TCP driver for read operations are exposed when an NVMe/TCP controller returns less data than the requested read length. A controller can cause a 4096-byte read to be reported as successful after sending only 512 bytes.
What does an attacker or malicious controller need to do to exploit it?
The controller needs to provide a short successful C2HData response for an NVMe/TCP read request. The driver can then complete the request as successful without verifying that the total received bytes match the requested length.
What is the impact of a successful short read?
User space can receive the requested buffer length even though only part of it came from the controller. The unread portion may contain data that was already present in the page, such as 3584 bytes in the described 4096-byte-read example.
How does the fix prevent the issue?
The fix counts bytes received for read requests and rejects successful completions when the received count does not match the command's requested length. The check is applied at the NVME_TCP_F_DATA_SUCCESS paths and during NVMe completion processing.