linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Sagi Grimberg <sagi@grimberg.me>
To: soni.ankit@samsung.com, kbusch@kernel.org, axboe@fb.com, hch@lst.de
Cc: linux-nvme@lists.infradead.org, sathya.m@samsung.com,
	d.palani@samsung.com, prakash.bv@samsung.com, anshul@samsung.com,
	ankitvvsoni@gmail.com
Subject: Re: [PATCH 1/1] nvme-tcp: check for invalid request
Date: Mon, 8 Apr 2024 14:08:15 +0300	[thread overview]
Message-ID: <516a90cb-c03f-4474-8456-056bb3bd87fc@grimberg.me> (raw)
In-Reply-To: <20240408045328.542327-1-soni.ankit@samsung.com>



On 08/04/2024 7:53, soni.ankit@samsung.com wrote:
> From: Ankit Soni <soni.ankit@samsung.com>
>
> The blk_mq_tag_to_rq() returns NULL for invalid tag.
> Added check condition to prevent NULL Pointer derefernece.

Does this fix an actual bug? Or a theoretic one?

>
> Signed-off-by: Ankit Soni <soni.ankit@samsung.com>
> ---
>   drivers/nvme/host/tcp.c | 34 ++++++++++++++++++++++------------
>   1 file changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
> index fdbcdcedcee9..01a90bbed70b 100644
> --- a/drivers/nvme/host/tcp.c
> +++ b/drivers/nvme/host/tcp.c
> @@ -801,9 +801,17 @@ static int nvme_tcp_recv_data(struct nvme_tcp_queue *queue, struct sk_buff *skb,
>   			      unsigned int *offset, size_t *len)
>   {
>   	struct nvme_tcp_data_pdu *pdu = (void *)queue->pdu;
> -	struct request *rq =
> -		nvme_cid_to_rq(nvme_tcp_tagset(queue), pdu->command_id);
> -	struct nvme_tcp_request *req = blk_mq_rq_to_pdu(rq);
> +	struct nvme_tcp_request *req;
> +	struct request *rq;
> +
> +	rq = nvme_cid_to_rq(nvme_tcp_tagset(queue), pdu->command_id);
> +	if (unlikely(!rq)) {
> +		pr_err("could not locate request for tag %#x\n",
> +			pdu->command_id);
> +		return -EFAULT;
> +	}
> +
> +	req = blk_mq_rq_to_pdu(rq);

We already checked the validity when processing the c2hpdu, there is no 
need to do
that for all the data payload chunks as well as it does not change.

>   
>   	while (true) {
>   		int recv_len, ret;
> @@ -875,6 +883,8 @@ static int nvme_tcp_recv_ddgst(struct nvme_tcp_queue *queue,
>   	char *ddgst = (char *)&queue->recv_ddgst;
>   	size_t recv_len = min_t(size_t, *len, queue->ddgst_remaining);
>   	off_t off = NVME_TCP_DIGEST_LENGTH - queue->ddgst_remaining;
> +	struct nvme_tcp_request *req;
> +	struct request *rq;
>   	int ret;
>   
>   	ret = skb_copy_bits(skb, *offset, &ddgst[off], recv_len);
> @@ -887,13 +897,17 @@ static int nvme_tcp_recv_ddgst(struct nvme_tcp_queue *queue,
>   	if (queue->ddgst_remaining)
>   		return 0;
>   
> -	if (queue->recv_ddgst != queue->exp_ddgst) {
> -		struct request *rq = nvme_cid_to_rq(nvme_tcp_tagset(queue),
> -					pdu->command_id);
> -		struct nvme_tcp_request *req = blk_mq_rq_to_pdu(rq);
> +	rq = nvme_cid_to_rq(nvme_tcp_tagset(queue), pdu->command_id);
> +	if (unlikely(!rq)) {
> +		pr_err("could not locate request for tag %#x\n",
> +			pdu->command_id);
> +		return -EFAULT;
> +	}

Same here, the ddgst comes as a trailer to a c2hdata pdu which we already
checked the validity, you are simply taking an already validated pdu and 
using
it. It is redundant.

>   
> -		req->status = cpu_to_le16(NVME_SC_DATA_XFER_ERROR);
> +	req = blk_mq_rq_to_pdu(rq);
>   
> +	if (queue->recv_ddgst != queue->exp_ddgst) {
> +		req->status = cpu_to_le16(NVME_SC_DATA_XFER_ERROR);
>   		dev_err(queue->ctrl->ctrl.device,
>   			"data digest error: recv %#x expected %#x\n",
>   			le32_to_cpu(queue->recv_ddgst),
> @@ -901,10 +915,6 @@ static int nvme_tcp_recv_ddgst(struct nvme_tcp_queue *queue,
>   	}
>   
>   	if (pdu->hdr.flags & NVME_TCP_F_DATA_SUCCESS) {
> -		struct request *rq = nvme_cid_to_rq(nvme_tcp_tagset(queue),
> -					pdu->command_id);
> -		struct nvme_tcp_request *req = blk_mq_rq_to_pdu(rq);
> -
>   		nvme_tcp_end_request(rq, le16_to_cpu(req->status));
>   		queue->nr_cqe++;
>   	}



  reply	other threads:[~2024-04-08 11:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20240408102150epcas5p2d5b4c3460fca7fe58520254a2466271b@epcas5p2.samsung.com>
2024-04-08  4:53 ` [PATCH 1/1] nvme-tcp: check for invalid request soni.ankit
2024-04-08 11:08   ` Sagi Grimberg [this message]
2024-04-16  2:43     ` Chaitanya Kulkarni

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=516a90cb-c03f-4474-8456-056bb3bd87fc@grimberg.me \
    --to=sagi@grimberg.me \
    --cc=ankitvvsoni@gmail.com \
    --cc=anshul@samsung.com \
    --cc=axboe@fb.com \
    --cc=d.palani@samsung.com \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=prakash.bv@samsung.com \
    --cc=sathya.m@samsung.com \
    --cc=soni.ankit@samsung.com \
    /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;
as well as URLs for NNTP newsgroup(s).