Hi, in fact, the target may send C2HTermReq.
zhang.guanghui@xxxxxxxx
发件人： Hannes Reinecke
发送时间： 2025-03-13 15:51
收件人： zhang.guanghui@xxxxxxxx; Maurizio Lombardi; sagi; mgurtovoy; kbusch; sashal; chunguang.xu
抄送： linux-kernel; linux-nvme; linux-block
主题： Re: nvme-tcp: fix a possible UAF when failing to send request【请注意，邮件由sagigrim@xxxxxxxxx代发】
On 3/13/25 02:48, zhang.guanghui@xxxxxxxx wrote:
> Yes, the problem here is that, despite the nvme_tcp_try_send() failure, the target sends a response capsule for the command, leading to a UAF in the host.
>
> Is it more reasonable to disable queue->rd_enabled to prevent receiving. Thanks
>
> diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
> index be04c5f3856d..17407eb12ad9 100644
> --- a/drivers/nvme/host/tcp.c
> +++ b/drivers/nvme/host/tcp.c
> @@ -1203,8 +1203,9 @@ static int nvme_tcp_try_send(struct nvme_tcp_queue *queue)
> } else if (ret < 0) {
> dev_err(queue->ctrl->ctrl.device,
> "failed to send request %d\n", ret);
> - nvme_tcp_fail_request(queue->request);
> nvme_tcp_done_send_req(queue);
> + queue->rd_enabled = false;
> + nvme_tcp_error_recovery(&queue->ctrl->ctrl);
> }
> out:
> memalloc_noreclaim_restore(noreclaim_flag);
>
>
>
Hmm. In principle, yes. Problem is that network is a bi-directional
communication, and a failure on one side doesn't necessarily imply
a failure on the other.
In particular when the send side fails we should _continue_ to read
as we should be flushing the read side buffer before closing.
So I agree with starting error recovery, but not with disabling the
reading side (as we haven't encountered a read error).
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
