[PATCH v3] nvmet: verify the hostid when looking up a controller

[Yifei Chu]

On Wed, Sep 02, 2026 at 04:04:00PM +0200, Christoph Hellwig wrote:
> So?  The hostid does not identify a controller.

Agreed, the controller is identified by cntlid and hostnqn. The
check is not about identifying the controller; it is about the host
identity bound to the controller at creation time:

- The fabrics connect path has a dedicated status for rejecting a
  connect because of the host identity: NVME_SC_CONNECT_INVALID_HOST
  (include/linux/nvme.h). nvmet already returns it from
  nvmet_alloc_ctrl() when the hostnqn is not allowed, but the hostid
  half of the host identity is never compared when io queues attach
  to an existing controller.

- The Linux host fills the same hostid into every connect capsule
  (nvmf_connect_data_prep() copies ctrl->opts->host->id, used by
  both the admin and the io connect path), and it refuses locally to
  pair one hostnqn with a different hostid ("maintain unambiguous
  host identification"). A conforming host therefore can never fail
  this check.

- nvmet consumes ctrl->hostid as the host identity: persistent
  reservation registrants and holders are keyed by it
  (drivers/nvme/target/pr.c). Letting an io connect with a different
  hostid attach its queues to the controller attributes those queues
  to a host the controller was not created for.

Comparing both halves of the host identity in the lookup is the
symmetric counterpart of the existing hostnqn comparison. If the
nvme maintainers disagree, I will drop the patch.

Yifei Chu