Database/Control plane, storage & DevOps
NVMe/TCP host: C2HData for a WRITE_ZEROES command writes into a stale iterator
Impact
The receive side gates an incoming C2HData PDU on blk_rq_payload_bytes() alone, without the blk_rq_nr_phys_segments() check that the submit side uses. REQ_OP_WRITE_ZEROES has no physical segments but a non-zero blk_rq_bytes(), so setup leaves req->iter untouched while the receive gate still lets the controller's data through, and nvme_tcp_recv_data() copies into whatever the previous command on that tag left in the iterator. The driver-private area is only zeroed when the tag set is allocated, so the stale pointer is real: the reporter shows KASAN reporting a wild-memory-access write of 512 bytes. A malicious or malfunctioning target therefore gets a controlled kernel write at an address it does not choose but the host does not validate - in practice a node crash, and potentially memory corruption on a host serving multiple tenants.
Who can reach it
The NVMe/TCP target, or anyone who can impersonate it on the storage network. Requires an active NVMe/TCP session and a WRITE_ZEROES command (discard/zeroing traffic) to land on a reused tag.
What to do
Update the host kernel to a stable release with the tightened receive gate (four stable commits linked) and reboot each NVMe/TCP client node. There is no configuration switch that disables WRITE_ZEROES issuance safely across all filesystems, so segmenting and authenticating the storage path is the only interim mitigation. No fixed release number is given.
References
Related entries
- 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
- PCIe Address Translation Services on hosts using an IOMMU/SMMU for device isolationNCVD-2019-005-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.