linux-kernel - Re: Re: nvme-tcp: fix a possible UAF when failing to send request【请注意，邮件由sagigrim@...il.com代发】

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2025031316185747646815@cestc.cn>
Date: Thu, 13 Mar 2025 16:18:57 +0800
From: "zhang.guanghui@...tc.cn" <zhang.guanghui@...tc.cn>
To: "Hannes Reinecke" <hare@...e.de>, 
	"Maurizio Lombardi" <mlombard@...backstore.eu>, 
	sagi <sagi@...mberg.me>, 
	mgurtovoy <mgurtovoy@...dia.com>, 
	kbusch <kbusch@...nel.org>, 
	sashal <sashal@...nel.org>, 
	chunguang.xu <chunguang.xu@...pee.com>
Cc: linux-kernel <linux-kernel@...r.kernel.org>, 
	linux-nvme <linux-nvme@...ts.infradead.org>, 
	linux-block <linux-block@...r.kernel.org>
Subject: Re: Re: nvme-tcp: fix a possible UAF when failing to send request【请注意，邮件由sagigrim@...il.com代发】

Hi,  in fact, the target may send C2HTermReq.




zhang.guanghui@...tc.cn



 



发件人： Hannes Reinecke



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



收件人： zhang.guanghui@...tc.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@...il.com代发】



On 3/13/25 02:48, zhang.guanghui@...tc.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@...e.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