From: Christoph Hellwig <hch@lst.de>
To: Alon Zahavi <zahavi.alon@gmail.com>
Cc: Chaitanya Kulkarni <chaitanyak@nvidia.com>,
Sagi Grimberg <sagi@grimberg.me>, Christoph Hellwig <hch@lst.de>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Subject: Re: [Bug Report] NVMe-oF/TCP - Slab OOB Read in `nvmet_ctrl_find_get`
Date: Wed, 8 Nov 2023 15:03:12 +0100 [thread overview]
Message-ID: <20231108140312.GA32730@lst.de> (raw)
In-Reply-To: <CAK5usQu_mi68_ChP4OckVmY42djdPx8L3hGg7_Jj0fa1yQ2mPw@mail.gmail.com>
On Wed, Nov 08, 2023 at 01:02:38PM +0200, Alon Zahavi wrote:
> I think that although those patches will fix the bug in the two
> functions we talked about, the non-terminated strings are still stored
> in the `struct nvmf_connect_data` object.
Yes, and that's a problem.
> Is it possible to add a NULL terminator after each time we use
> `nvmet_copy_from_sgl()` to copy from an SGL to `struct
> nvmf_connect_data` object?
Yes, and that is the best thing to do in the short term as it's
easily backportable. I'd much prefer to move to counted strings as
in the seq_buf type, but that is a longer term project.
> Also, I think `nvmet_copy_from_sgl()` should be considered as unsafe
> when using it to copy strings, as it doesn't check for NULL
> termination.
Think of nvmet_copy_from_sgl as a memcpy from a different address
space. It works on a very different abstraction layer and thus
doesn't even know about strings. The callers really need to,
and maybe we want a helper for that. For now that patch below should
fix the issue you reported, although for me KASAN doesn't trip up
on the reproducer with or without the patch, so if you could test it
on your setup that would be great:
diff --git a/drivers/nvme/target/fabrics-cmd.c b/drivers/nvme/target/fabrics-cmd.c
index 43b5bd8bb6a52d..0920fe7ce4ac99 100644
--- a/drivers/nvme/target/fabrics-cmd.c
+++ b/drivers/nvme/target/fabrics-cmd.c
@@ -244,6 +244,8 @@ static void nvmet_execute_admin_connect(struct nvmet_req *req)
goto out;
}
+ d->subsysnqn[NVMF_NQN_FIELD_LEN] = '\0';
+ d->hostnqn[NVMF_NQN_FIELD_LEN] = '\0';
status = nvmet_alloc_ctrl(d->subsysnqn, d->hostnqn, req,
le32_to_cpu(c->kato), &ctrl);
if (status)
@@ -313,6 +315,8 @@ static void nvmet_execute_io_connect(struct nvmet_req *req)
goto out;
}
+ d->subsysnqn[NVMF_NQN_FIELD_LEN] = '\0';
+ d->hostnqn[NVMF_NQN_FIELD_LEN] = '\0';
ctrl = nvmet_ctrl_find_get(d->subsysnqn, d->hostnqn,
le16_to_cpu(d->cntlid), req);
if (!ctrl) {
next prev parent reply other threads:[~2023-11-08 14:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-06 13:37 [Bug Report] NVMe-oF/TCP - Slab OOB Read in `nvmet_ctrl_find_get` Alon Zahavi
2023-11-08 8:46 ` Chaitanya Kulkarni
2023-11-08 9:01 ` Alon Zahavi
2023-11-08 10:02 ` Chaitanya Kulkarni
2023-11-08 11:02 ` Alon Zahavi
2023-11-08 14:03 ` Christoph Hellwig [this message]
2023-11-08 22:09 ` Chaitanya Kulkarni
2023-11-09 4:52 ` Christoph Hellwig
2023-11-09 8:49 ` 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=20231108140312.GA32730@lst.de \
--to=hch@lst.de \
--cc=chaitanyak@nvidia.com \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=zahavi.alon@gmail.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