Database/Control plane, storage & DevOps
NVMe/TCP host: a short read is reported to userspace as a complete read
Impact
nvme_tcp_recv_data() completes a request when the current C2HData PDU has been consumed, and nothing compares the total bytes received against the length the command asked for - there is no receive-side counter per request and blk_mq_end_request() completes for blk_rq_bytes(rq) unconditionally. A controller can answer a 4096-byte read with 512 bytes and have it reported as a successful full read; userspace then receives 4096 bytes of which 3584 are whatever was already in the page. That is silent data corruption plus disclosure of stale page contents, with no error surfaced to the application or the filesystem above it - on a fleet whose datasets, checkpoints or container images live on NVMe/TCP, corrupt data is accepted as good. Only REQ_OP_READ is checked by the fix, because for passthrough commands the submitter picks both command and buffer and the kernel has nothing to compare against.
Who can reach it
The NVMe/TCP target, or anyone able to impersonate or tamper with that connection. Requires an established NVMe/TCP session; a buggy target reaches the same outcome without malice.
What to do
Patch the host kernel to a stable release carrying the byte-count check (four stable commits linked) and reboot each NVMe/TCP client node. No runtime workaround exists on the host side. No fixed release number is stated in the record.
References
Related entries
- NVMe/TCP host: a malicious target can read host kernel memory by sending R2T for a READCVE-2026-89481 · Linux kernel nvme-tcp host (R2T direction check)Unscored
- NVMe/TCP host: C2HData for a WRITE_ZEROES command writes into a stale iteratorCVE-2026-89482 · Linux kernel nvme-tcp host (C2HData receive gate, WRITE_ZEROES path)Unscored
- Linux kernel nvme: discard fallback page is never zeroed, leaking kernel memory to the controllerCVE-2026-89483 · Linux kernel nvme core (DSM discard fallback page)Unscored
- Linux CephFS client: leaked inode reference on aborted writeback panics the node at umountCVE-2026-89646 · Linux kernel CephFS client (ceph_submit_write writeback abort at umount)Unscored
- Linux CephFS client: cap reclaim work busy-loops, burning CPU and contending dentry_list_lockCVE-2026-89647 · Linux kernel CephFS client (ceph_cap_reclaim_work / ceph_trim_dentries busy loop)Unscored
- Linux CephFS client: unbounded delegated-inode intervals let a hostile MDS burn client CPU and memoryCVE-2026-89648 · Linux kernel CephFS client (ceph_parse_deleg_inos delegated inode count)Unscored
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.