From: Yifei Chu <Chuyf26@linux.alibaba.com>
To: Keith Busch <kbusch@kernel.org>
Cc: Sagi Grimberg <sagi@grimberg.me>, Christoph Hellwig <hch@lst.de>,
linux-nvme@lists.infradead.org
Subject: [PATCH v2] nvmet: verify the hostid when looking up a controller
Date: Thu, 27 Aug 2026 18:12:12 +0800 [thread overview]
Message-ID: <178782553270.1581249.13595405857993482779@linux.alibaba.com> (raw)
nvmet_ctrl_find_get() matches controllers by cntlid and hostnqn only.
The connect data also carries the connecting host's hostid, but it is
never compared against the hostid the controller was created with, so
the lookup can return a controller whose recorded hostid differs.
Controller IDs are allocated sequentially and easy to guess, and
nothing prevents two hosts from using the same hostnqn (misconfigured
clones, or a reinstalled host whose controller still exists). Such a
host currently attaches its queues to the other host's controller and
shares its controller state with it. Also require the hostid from the
connect data to match the controller's hostid so that the lookup is
bound to the identity the controller was created with.
Controllers that were created without a hostid keep the old behaviour.
Fixes: a07b4970f464 ("nvmet: add a generic NVMe target")
Reported-by: Abaci <abaci@linux.alibaba.com>
Assisted-by: abaci:qwen3.8-max
Signed-off-by: Yifei Chu <Chuyf26@linux.alibaba.com>
---
v2: reword the changelog as a correctness fix instead of a security
fix, the hostid is not a secret either (Sagi).
Previous thread:
https://lore.kernel.org/all/178707054946.2644927.16076495238405774277@linux.alibaba.com/
drivers/nvme/target/core.c | 12 ++++++++++++
drivers/nvme/target/fabrics-cmd.c | 2 +-
drivers/nvme/target/nvmet.h | 1 +
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/nvme/target/core.c b/drivers/nvme/target/core.c
index d74c01c..f1eb5cc 100644
--- a/drivers/nvme/target/core.c
+++ b/drivers/nvme/target/core.c
@@ -1471,6 +1471,7 @@ static void nvmet_init_cap(struct nvmet_ctrl *ctrl)
struct nvmet_ctrl *nvmet_ctrl_find_get(const char *subsysnqn,
const char *hostnqn, u16 cntlid,
+ const uuid_t *hostid,
struct nvmet_req *req)
{
struct nvmet_ctrl *ctrl = NULL;
@@ -1491,6 +1492,17 @@ struct nvmet_ctrl *nvmet_ctrl_find_get(const char *subsysnqn,
pr_warn("hostnqn mismatch.\n");
continue;
}
+ /*
+ * Also require the hostid from the connect data to
+ * match the hostid the controller was created with.
+ * Accept a nil hostid only if the controller was
+ * created without one.
+ */
+ if (!uuid_is_null(&ctrl->hostid) &&
+ !uuid_equal(&ctrl->hostid, hostid)) {
+ pr_warn("hostid mismatch.\n");
+ continue;
+ }
if (!kref_get_unless_zero(&ctrl->ref))
continue;
diff --git a/drivers/nvme/target/fabrics-cmd.c b/drivers/nvme/target/fabrics-cmd.c
index 42d1d18..5e2487d 100644
--- a/drivers/nvme/target/fabrics-cmd.c
+++ b/drivers/nvme/target/fabrics-cmd.c
@@ -364,7 +364,7 @@ static void nvmet_execute_io_connect(struct nvmet_req *req)
d->subsysnqn[NVMF_NQN_FIELD_LEN - 1] = '\0';
d->hostnqn[NVMF_NQN_FIELD_LEN - 1] = '\0';
ctrl = nvmet_ctrl_find_get(d->subsysnqn, d->hostnqn,
- le16_to_cpu(d->cntlid), req);
+ le16_to_cpu(d->cntlid), &d->hostid, req);
if (!ctrl) {
status = NVME_SC_CONNECT_INVALID_PARAM | NVME_STATUS_DNR;
goto out;
diff --git a/drivers/nvme/target/nvmet.h b/drivers/nvme/target/nvmet.h
index e362d79..52ea4c7 100644
--- a/drivers/nvme/target/nvmet.h
+++ b/drivers/nvme/target/nvmet.h
@@ -623,6 +623,7 @@ struct nvmet_alloc_ctrl_args {
struct nvmet_ctrl *nvmet_alloc_ctrl(struct nvmet_alloc_ctrl_args *args);
struct nvmet_ctrl *nvmet_ctrl_find_get(const char *subsysnqn,
const char *hostnqn, u16 cntlid,
+ const uuid_t *hostid,
struct nvmet_req *req);
void nvmet_ctrl_put(struct nvmet_ctrl *ctrl);
u16 nvmet_check_ctrl_status(struct nvmet_req *req);
--
2.43.5
next reply other threads:[~2026-08-27 10:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 10:12 Yifei Chu [this message]
2026-08-30 21:27 ` [PATCH v2] nvmet: verify the hostid when looking up a controller Sagi Grimberg
2026-08-31 2:36 ` [PATCH v3] " Yifei Chu
2026-09-02 14:04 ` Christoph Hellwig
2026-09-03 2:37 ` Yifei Chu
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=178782553270.1581249.13595405857993482779@linux.alibaba.com \
--to=chuyf26@linux.alibaba.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.