NVMe/TCP host: a malicious target can read host kernel memory by sending R2T for a READ

Impact

The strongest of the nvme-tcp bugs in this batch. nvme_tcp_handle_r2t() never checks the direction of the command an R2T refers to, so a controller that answers a READ with a Ready-to-Transfer gets the host to send the READ's destination buffer back over the wire. The reporter's test controller recovered all 4096 bytes of a buffered read, and the pages held stale kernel data including an array of struct page pointers - that is host kernel memory disclosure, useful for defeating KASLR and for staging further attacks. The command then completes normally and nothing is logged, so there is no operator-visible trace. For a GPU fleet this matters wherever nodes boot from or mount NVMe/TCP targets over the storage network: a compromised or spoofed storage target, or anyone who can occupy that path, harvests kernel memory from every client node it serves.

Who can reach it

The NVMe/TCP target, or anyone able to impersonate or sit in the path to it on the storage network. Requires an established NVMe/TCP connection, so it is an attack by (or through) the storage service the host already trusts, not by an unauthenticated stranger on the LAN.

What to do

Patch the host kernel to a stable release containing the direction check (four stable commits linked) and reboot each NVMe/TCP client node; nvme-tcp is the host driver, so a node reboot or at minimum a full disconnect/module reload plus reconnect of every subsystem is required. Until then, the only mitigation is to make sure the storage path cannot be occupied by an untrusted party - segment the storage network and use NVMe/TCP TLS or authentication where the target supports it. No fixed release number is stated in the record.

References

Related entries

• 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
• Linux CephFS client: unchecked final xattr value length leaks kernel heap via getxattr(2)CVE-2026-89649 · Linux kernel CephFS client (__build_xattrs xattr value length)Unscored