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

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

[Chuyf26]

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.

Reject C2HData for any non-read command.  This is the symmetric case
of commit 6efbc52237fa ("nvme-tcp: fix host memory disclosure on R2T
for a read command"), which added the mirror-image direction check to
nvme_tcp_handle_r2t().

Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver")
Cc: stable@vger.kernel.org
Reported-by: Abaci <abaci@linux.alibaba.com>
Assisted-by: abaci:qwen3.8-max
Signed-off-by: Chuyf26 <Chuyf26@linux.alibaba.com>
---
 drivers/nvme/host/tcp.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
--- a/drivers/nvme/host/tcp.c
+++ b/drivers/nvme/host/tcp.c
@@ -685,6 +685,13 @@
 	}
 
 	req = blk_mq_rq_to_pdu(rq);
+	if (unlikely(rq_data_dir(rq) != READ)) {
+		dev_err(queue->ctrl->ctrl.device,
+			"req %d unexpected c2hdata for a non-read command\n",
+			rq->tag);
+		return -EPROTO;
+	}
+
 	if (!blk_rq_payload_bytes(rq) || !req->curr_bio || !req->data_len) {
 		dev_err(queue->ctrl->ctrl.device,
 			"queue %d tag %#x unexpected data\n",
-- 
2.43.5

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

[Sagi Grimberg]

On 21/08/2026 12:28, Chuyf26 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.
>
> Reject C2HData for any non-read command.  This is the symmetric case
> of commit 6efbc52237fa ("nvme-tcp: fix host memory disclosure on R2T
> for a read command"), which added the mirror-image direction check to
> nvme_tcp_handle_r2t().
>
> Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver")
> Cc: stable@vger.kernel.org
> Reported-by: Abaci <abaci@linux.alibaba.com>
> Assisted-by: abaci:qwen3.8-max
> Signed-off-by: Chuyf26 <Chuyf26@linux.alibaba.com>
> ---
>   drivers/nvme/host/tcp.c | 7 +++++++
>   1 file changed, 7 insertions(+)
>
> diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
> --- a/drivers/nvme/host/tcp.c
> +++ b/drivers/nvme/host/tcp.c
> @@ -685,6 +685,13 @@
>   	}
>   
>   	req = blk_mq_rq_to_pdu(rq);
> +	if (unlikely(rq_data_dir(rq) != READ)) {
> +		dev_err(queue->ctrl->ctrl.device,
> +			"req %d unexpected c2hdata for a non-read command\n",
> +			rq->tag);
> +		return -EPROTO;
> +	}
> +

It'd be better to check this before the req assignment.

Other than that, this looks good.

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

[Yifei Chu]

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.

Reject C2HData for any non-read command.  This is the symmetric case
of commit 6efbc52237fa ("nvme-tcp: fix host memory disclosure on R2T
for a read command"), which added the mirror-image direction check to
nvme_tcp_handle_r2t().

Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver")
Cc: stable@vger.kernel.org
Reported-by: Abaci <abaci@linux.alibaba.com>
Assisted-by: abaci:qwen3.8-max
Signed-off-by: Yifei Chu <Chuyf26@linux.alibaba.com>
---
v2: move the direction check before the req assignment (Sagi).
    Keep -EPROTO (Sagi: "EPROTO is more appropriate").

 drivers/nvme/host/tcp.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
index 5fda966..60d7c37 100644
--- a/drivers/nvme/host/tcp.c
+++ b/drivers/nvme/host/tcp.c
@@ -684,6 +684,13 @@ static int nvme_tcp_handle_c2h_data(struct nvme_tcp_queue *queue,
 		return -ENOENT;
 	}
 
+	if (unlikely(rq_data_dir(rq) != READ)) {
+		dev_err(queue->ctrl->ctrl.device,
+			"req %d unexpected c2hdata for a non-read command\n",
+			rq->tag);
+		return -EPROTO;
+	}
+
 	req = blk_mq_rq_to_pdu(rq);
 	if (!blk_rq_payload_bytes(rq) || !req->curr_bio || !req->data_len) {
 		dev_err(queue->ctrl->ctrl.device,
-- 
2.43.5

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

[Sagi Grimberg]

Reviewed-by: Sagi Grimberg <sagi@grimberg.me>

Re: [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