All of lore.kernel.org
 help / color / mirror / Atom feed
From: "zhang.guanghui@cestc.cn" <zhang.guanghui@cestc.cn>
To: "Hannes Reinecke" <hare@suse.de>,
	 "Maurizio Lombardi" <mlombard@bsdbackstore.eu>,
	 sagi <sagi@grimberg.me>,  mgurtovoy <mgurtovoy@nvidia.com>,
	 kbusch <kbusch@kernel.org>,  sashal <sashal@kernel.org>,
	 chunguang.xu <chunguang.xu@shopee.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	 linux-nvme <linux-nvme@lists.infradead.org>,
	 linux-block <linux-block@vger.kernel.org>
Subject: Re: Re: nvme-tcp: fix a possible UAF when failing to send request【请注意,邮件由sagigrim@gmail.com代发】
Date: Thu, 13 Mar 2025 16:18:57 +0800	[thread overview]
Message-ID: <2025031316185747646815@cestc.cn> (raw)
In-Reply-To: deb1584c-67b8-4543-9017-9ca18a9ee7d8@suse.de

Hi,  in fact, the target may send C2HTermReq.




zhang.guanghui@cestc.cn



 



发件人: Hannes Reinecke



发送时间: 2025-03-13 15:51



收件人: zhang.guanghui@cestc.cn; 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@gmail.com代发】



On 3/13/25 02:48, zhang.guanghui@cestc.cn 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@suse.de                                +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



 



 



  reply	other threads:[~2025-03-13  8:19 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-10  7:41 nvme-tcp: fix a possible UAF when failing to send request zhang.guanghui
2025-02-10 10:01 ` Maurizio Lombardi
2025-02-10 10:24   ` Max Gurtovoy
2025-02-10 11:16     ` zhang.guanghui
2025-02-10 11:34       ` Max Gurtovoy
2025-02-10 16:40     ` Maurizio Lombardi
     [not found]       ` <CAAO4dAWdsMjYMp9jdWXd_48aG0mTtVpRONqjJJ1scnc773tHzg@mail.gmail.com>
2025-02-11  8:04         ` zhang.guanghui
2025-02-12  8:11           ` Maurizio Lombardi
2025-02-12  8:23             ` Maurizio Lombardi
2025-02-12  8:52             ` Maurizio Lombardi
2025-02-12  9:47               ` zhang.guanghui
2025-02-12 10:28                 ` Maurizio Lombardi
2025-02-12 11:14                   ` Maurizio Lombardi
2025-02-12 11:47                     ` Maurizio Lombardi
2025-02-12 15:33 ` Maurizio Lombardi
2025-02-12 16:07   ` Maurizio Lombardi
2025-02-13  2:04     ` zhang.guanghui
2025-02-17  7:46 ` Sagi Grimberg
2025-02-20  8:20   ` zhang.guanghui
2025-03-07 10:10   ` Re: nvme-tcp: fix a possible UAF when failing to send request【请注意,邮件由sagigrim@gmail.com代发】 zhang.guanghui
2025-03-11 10:52     ` Maurizio Lombardi
2025-03-13  1:48       ` zhang.guanghui
2025-03-13  7:51         ` Hannes Reinecke
2025-03-13  8:18           ` zhang.guanghui [this message]
     [not found]             ` <2025031316313196627826@cestc.cn>
2025-03-13  9:01               ` Maurizio Lombardi
2025-03-13  8:38           ` zhang.guanghui
2025-03-28  9:24       ` Re: nvme-tcp: fix a possible UAF when failing to send request zhang.guanghui
2025-04-01 12:11         ` Maurizio Lombardi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2025031316185747646815@cestc.cn \
    --to=zhang.guanghui@cestc.cn \
    --cc=chunguang.xu@shopee.com \
    --cc=hare@suse.de \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=mgurtovoy@nvidia.com \
    --cc=mlombard@bsdbackstore.eu \
    --cc=sagi@grimberg.me \
    --cc=sashal@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.