Re: [PATCH v2 03/14] nvmet: Implement CCR nvme command

[Hannes Reinecke]

On 2/4/26 01:44, Mohamed Khalfella wrote:
> On Wed 2026-02-04 01:38:44 +0100, Hannes Reinecke wrote:
> > On 2/3/26 19:40, Mohamed Khalfella wrote:
> > > On Tue 2026-02-03 04:19:50 +0100, Hannes Reinecke wrote:
> > > > On 1/30/26 23:34, Mohamed Khalfella wrote:
> > > > > @@ -1501,6 +1516,38 @@ struct nvmet_ctrl *nvmet_ctrl_find_get(const char *subsysnqn,
> > > > >     	return ctrl;
> > > > >     }
> > > > >     
> > > > > +struct nvmet_ctrl *nvmet_ctrl_find_get_ccr(struct nvmet_subsys *subsys,
> > > > > +					   const char *hostnqn, u8 ciu,
> > > > > +					   u16 cntlid, u64 cirn)
> > > > > +{
> > > > > +	struct nvmet_ctrl *ctrl;
> > > > > +	bool found = false;
> > > > > +
> > > > > +	mutex_lock(&subsys->lock);
> > > > > +	list_for_each_entry(ctrl, &subsys->ctrls, subsys_entry) {
> > > > > +		if (ctrl->cntlid != cntlid)
> > > > > +			continue;
> > > > > +		if (strncmp(ctrl->hostnqn, hostnqn, NVMF_NQN_SIZE))
> > > > > +			continue;
> > > > > +
> > > > Why do we compare the hostnqn here, too? To my understanding the host
> > > > NQN is tied to the controller, so the controller ID should be sufficient
> > > > here.
> > >
> > > We got cntlid from CCR nvme command and we do not trust the value sent by
> > > the host. We check hostnqn to confirm that host is actually connected to
> > > the impacted controller. A host should not be allowed to reset a
> > > controller connected to another host.
> > Errm. So we're starting to not trust values in NVMe commands?
> > That is a very slippery road.
> > Ultimately it would require us to validate the cntlid on each
> > admin command. Which we don't.
> > And really there is no difference between CCR and any other
> > admin command; you get even worse effects if you would assume
> > a misdirected 'FORMAT' command.
> >
> > Please don't. Security is _not_ a concern here.
>
> I do not think the check hurts. If you say it is wrong I will delete it.
It's not 'wrong', It's inconsistent. The argument that the contents of
an admin command may be wrong applies to _every_ admin command.
Yet we never check on any of those commands.
So I fail to see why this command requires special treatment.

Cheers,

Hannes
--
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@xxxxxxx                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich