public inbox for linux-nvme@lists.infradead.org
 help / color / mirror / Atom feed
From: "zhang.guanghui@cestc.cn" <zhang.guanghui@cestc.cn>
To: "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
Date: Thu, 13 Feb 2025 10:04:12 +0800	[thread overview]
Message-ID: <2025021310041218941132@cestc.cn> (raw)
In-Reply-To: D7QLI3PYQ877.1KH6K8K08P2IP@bsdbackstore.eu


Hi 
     int fact,  the commit aeacfcefa218f4ed11da478e9b7915a37d1afaff  has been synchronized, but the issue still occurs.

    I think so, when the host failing to send request -13,   maybe only part of the command has been sent or  the controller has receved  a complete command.
but the controller may send nvme_tcp_rsp  and  C2HTermReq consecutively.  Now I am analyzing the controller spdk processing logic. 
when the host uses nvme_tcp_poll,  it receives nvme_tcp_rsp and handles it firstly,    
then the host  have a UAF and crashed.   




zhang.guanghui@cestc.cn



 



From: Maurizio Lombardi



Date: 2025-02-13 00:07



To: Maurizio Lombardi; zhang.guanghui@cestc.cn; sagi; mgurtovoy; kbusch; sashal; chunguang.xu



CC: linux-kernel; linux-nvme; linux-block



Subject: Re: nvme-tcp: fix a possible UAF when failing to send request



On Wed Feb 12, 2025 at 4:33 PM CET, Maurizio Lombardi wrote:



>



> Taking a step back. Let's take a different approach and try to avoid the



> double completion.



>



> The problem here is that apparently we received a nvme_tcp_rsp capsule



> from the target, meaning that the command has been processed (I guess



> the capsule has an error status?)



>



> So maybe only part of the command has been sent?



> Why we receive the rsp capsule at all? Shouldn't this be treated as a fatal



> error by the controller?  

--


 



 



> The NVMe/TCP specification says



 



******



When a controller detects a fatal error, that controller shall:



  1. stop processing any PDUs that arrive on the connection; and



  2. send a C2HTermReq PDU



******



 



And indeed I see in the dmesg this:



 



nvme nvme2: unsupported pdu type (3)



 



This means the controller detected the problem and sent to the host the



C2HTermReq command. Upon receiving this command, the host is supposed to



close the connection.



 



Now I get it.



 



Zhang, do you have commit aeacfcefa218f4ed11da478e9b7915a37d1afaff in



your kernel, I guess you are missing it. Check it please.



 



Maurizio



 



 



 



  reply	other threads:[~2025-02-13  2:05 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 [this message]
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
     [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=2025021310041218941132@cestc.cn \
    --to=zhang.guanghui@cestc.cn \
    --cc=chunguang.xu@shopee.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox