[PATCH v2] nvme-tcp: reject C2HData for a non-read command

[Keith Busch]

On Thu, Sep 03, 2026 at 05:20:01PM +0800, Yifei Chu wrote:
> A malicious or buggy controller can send C2HData PDUs in response to a
> WRITE command.  nvme_tcp_handle_c2h_data() accepts them as long as the
> request has payload bytes and a current bio, which is true for writes,
> so the receive path ends up copying the incoming data into the
> request's iterator.  That iterator was initialized from rq_data_dir(rq)
> in nvme_tcp_init_iter(), i.e. ITER_SOURCE for a write, and
> _copy_to_iter() refuses to copy into a source iterator: it triggers its
> WARN_ON_ONCE() and returns 0, the short copy fails with -EFAULT, and
> the connection is torn down into error recovery.  The write never
> completes: every reconnect reissues it and a malicious target answers
> with C2HData again, keeping the controller in a permanent
> reset/reconnect loop.  With panic_on_warn this is an outright crash.
> 
> C2HData carries data transferred from the controller to the host and
> is only valid for commands that read data from the device; write data
> travels host to controller in H2CData PDUs solicited by R2T.  This was
> reproduced against a target modified to reply to a WRITE with C2HData:
> the host logs
> 
>     WARNING: CPU: 0 PID: ... at lib/iov_iter.c _copy_to_iter
>     Workqueue: nvme_tcp_wq nvme_tcp_io_work [nvme_tcp]
> 
> and the controller cycles through reset/reconnect without the write
> ever completing.

This is already closed:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=f83af377c148f6ad94b41c0e8313f12adf45e1c1