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++;
> }
next prev parent 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).