GPU VulnDB

Database/Control plane, storage & DevOps

NVMe/TCP host: C2HData for a WRITE_ZEROES command writes into a stale iterator

UnscoredCVE-2026-89482Control plane, storage & DevOpscurated

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

All Control plane, storage & DevOps entries

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.