Linux kernel nvmet-tcp - ICReq/teardown race and data-digest error paths: Three lifecycle bugs an initiator can drive

Impact

Three lifecycle bugs an initiator can drive on purpose. Send an ICReq and immediately close the socket and the target's queue state gets flipped back to LIVE after teardown already started, defeating the DISCONNECTING guard and leading to use-after-free. Negotiate data digests and deliberately mismatch one on a non-final H2C_DATA PDU and the target either underflows a refcount into a permanent workqueue deadlock or leaves a half-uninitialised command that teardown uninits a second time. The workqueue deadlock variant is the one that hurts operationally: the target stops serving I/O for every tenant and only a reboot clears it, so a single initiator - including a tenant VM with a legitimately provisioned namespace - can take the whole storage node down on demand and repeat it after every restart.

Who can reach it

Any host that can open an NVMe/TCP connection to the target. For the digest variants the attacker needs a connection that negotiates data digests, which any initiator can request; no valid namespace or credential is required for the ICReq race.

What to do

Kernel update on the target nodes and a reboot. Disabling data digests removes two of the three but not the ICReq race, and costs you the end-to-end integrity check, so it is a poor trade. Because these are cheap remote denial-of-service primitives rather than deep exploitation, prioritise them by blast radius: any target serving more than one tenant should be patched before targets serving one. Rate-limiting or per-initiator connection caps on the storage VLAN reduce the repeat rate but do not fix it.

References