Database/Control plane, storage & DevOps
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
- Tenant handoff on bare metal: Reimaging the host disk clears nothing in the BMC, UEFI/SPI flash, NIC/DPU firmware, GPUNCVD-0000-013-tenant-handoff-on-bare-metal · Tenant handoff on bare metalUnscored
- ECC DDR3 server memory on Intel Xeon (Haswell, Sandy Bridge) and AMD Opteron platformsNCVD-2018-002-ecc-ddr3-server-memory-on-intel · ECC DDR3 server memory on Intel Xeon (Haswell, Sandy Bridge) and AMD Opteron platforms; the technique generalises to…Unscored
- ECC DDR3 server memory on Intel Xeon (Haswell, Sandy Bridge) and AMD Opteron platformsNCVD-2018-004-ecc-ddr3-server-memory-on-intel · ECC DDR3 server memory on Intel Xeon (Haswell, Sandy Bridge) and AMD Opteron platforms; the technique generalises to…Unscored
- PCIe Address Translation Services on hosts using an IOMMU/SMMU for device isolationNCVD-2019-001-pcie-address-translation-service · PCIe Address Translation Services on hosts using an IOMMU/SMMU for device isolation - affects any DMA-capable…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.