CVE-2026-89480
moderateLinux kernel NVMe/TCP short-read flaw lets malicious target leak stale page data
The Linux kernel's NVMe over TCP host driver (nvme-tcp) completes a read request as soon as the current C2HData PDU is consumed, without ever comparing the total bytes received against the length the command asked for. A malicious or compromised NVMe/TCP controller (storage target) can exploit this by answering, for example, a 4096-byte read with only 512 bytes; the kernel marks the read complete and userspace receives the full 4096-byte buffer, where the missing 3584 bytes are stale data left over in the page, potentially disclosing sensitive kernel memory. Any Linux host using the nvme-tcp initiator against an untrusted or compromised NVMe/TCP target is affected, with a CVSS 3.1 base score of 7.5 (high) driven by the confidentiality impact. The fix counts received bytes and refuses to complete a successful read whose count does not match, enforced at the two NVME_TCP_F_DATA_SUCCESS paths and in nvme_tcp_process_nvme_cqe(). There is no known public proof of concept, the CVE is not in CISA's KEV catalog, and no exploitation in the wild has been reported.
What to do: Update to a kernel containing the upstream nvme-tcp fix (the patch that counts received bytes and refuses to complete short reads at the two NVME_TCP_F_DATA_SUCCESS paths and in nvme_tcp_process_nvme_cqe()); check your distribution's kernel advisory for the backported version. Audit whether you use NVMe/TCP at all (e.g., nvme connect -t tcp or configured nvme-tcp subsystems) — hosts attaching only physically secured, trusted storage arrays face substantially lower risk. Consider enabling NVMe in-band authentication (DH-HMAC-CHAP) or TLS on nvme-tcp connections so an unauthenticated party cannot impersonate the controller, and re-verify critical data read from any suspect target.
| Linux kernel (nvme-tcp host driver) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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.
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
In the news0 stories
No ingested article mentions this CVE yet.