Re: [PATCH v2 23/33] ibmvfc: implement NVMe/FC stubs for local/remote port registration

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Overwriting the NVMe-FC transport's pre-allocated `private` pointer in port registration functions causes API misuse and out-of-bounds memory corruption.
- [Medium] The NVMe-FC transport stubs (`ibmvfc_nvme_ls_req` and `ibmvfc_nvme_fcp_io`) return 0 (success) but drop requests without invoking the mandatory asynchronous `done` callbacks, causing uninterruptible hangs.
--

--- Patch [23]: [PATCH v2 23/33] ibmvfc: implement NVMe/FC stubs for local/remote port registration ---
commit a018152524c65e5db110e234e12e5b6d56bbe966
Author: Tyrel Datwyler <tyreld@linux.ibm.com>

ibmvfc: implement NVMe/FC stubs for local/remote port registration

Implement the initial NVMe/FC local-port and remote-port registration
functions that notify the NVMe-FC midlayr of port discovery and loss.

Register the local port with the NVMe-FC transport, register discovered
remote ports against that local port, and add matching unregister paths
that wait for the NVMe-FC core to complete asynchronous deletion before
dropping driver references. Also store driver-private host and target
pointers in the registered NVMe-FC port objects.

> diff --git a/drivers/scsi/ibmvscsi/ibmvfc-nvme.c b/drivers/scsi/ibmvscsi/ibmvfc-nvme.c
> index 2ee1c64665d9c..d679d1ca366a8 100644
> --- a/drivers/scsi/ibmvscsi/ibmvfc-nvme.c
> +++ b/drivers/scsi/ibmvscsi/ibmvfc-nvme.c
> @@ -14,10 +14,18 @@
>  
>  static void ibmvfc_nvme_localport_delete(struct nvme_fc_local_port *lport)
>  {
> +	struct ibmvfc_host *vhost = lport->private;
> +
> +	vhost->nvme_local_port = NULL;
> +	complete(&vhost->nvme_delete_done);
>  }
>  
>  static void ibmvfc_nvme_remoteport_delete(struct nvme_fc_remote_port *rport)
>  {
> +	struct ibmvfc_target *tgt = rport->private;
> +
> +	tgt->nvme_remote_port = NULL;
> +	complete(&tgt->nvme_delete_done);
>  }

[Severity: Medium]
If a concurrent teardown unregisters the port before the private pointer
is overwritten during registration, could rport->private still point to the
8-byte inline buffer allocated by the NVMe-FC core?

If so, won't casting this 8-byte buffer to a much larger struct ibmvfc_target
and writing to tgt->nvme_remote_port cause an out-of-bounds write and memory
corruption?

>  
>  static int ibmvfc_nvme_ls_req(struct nvme_fc_local_port *lport,

[Severity: Medium]
Do the NVMe-FC transport stubs (ibmvfc_nvme_ls_req and ibmvfc_nvme_fcp_io)
return 0 without invoking the mandatory asynchronous done callbacks?

If these functions return 0 (success) but drop requests without calling
ls_req->done or fcp_req->done, won't this leave the NVMe-FC core waiting
forever, potentially causing an uninterruptible hang?

[ ... ]

> @@ -70,28 +78,96 @@ static struct nvme_fc_port_template ibmvfc_nvme_fc_transport = {
>  
>  int ibmvfc_nvme_register_remoteport(struct ibmvfc_target *tgt)
>  {
> +	struct ibmvfc_host *vhost = tgt->vhost;
> +	struct nvme_fc_port_info pinfo;
> +	int rc;
> +
>  	if (!IS_ENABLED(CONFIG_NVME_FC))
>  		return 0;
>  
> -	return 0;
> +	if (!vhost->nvme_local_port) {
> +		dev_err(vhost->dev, "Attempt to register NVMe fc remoteport without valid localport\n");
> +		return -EINVAL;
> +	}
> +
> +	memset(&pinfo, 0, sizeof(struct nvme_fc_port_info));
> +	pinfo.node_name = tgt->ids.node_name;
> +	pinfo.port_name = tgt->ids.port_name;
> +	pinfo.port_id = tgt->ids.port_id;
> +	pinfo.port_role = FC_PORT_ROLE_NVME_TARGET;
> +
> +	rc = nvme_fc_register_remoteport(vhost->nvme_local_port, &pinfo,
> +					 &tgt->nvme_remote_port);
> +
> +	if (!rc) {
> +		ibmvfc_log(vhost, 2, "register_remoteport: traddr=nn-0x%llx:pn-0x%llx PortID:%x\n",
> +			   pinfo.node_name, pinfo.port_name, pinfo.port_id);
> +		tgt->nvme_remote_port->private = tgt;

[Severity: Medium]
Does directly overwriting the nvme_remote_port->private pointer orphan the
inline buffer allocated by the NVMe-FC core?

Since the NVMe-FC core allocates an 8-byte inline buffer for private data
based on remote_priv_sz, shouldn't the data be copied into the allocated
buffer rather than overwriting the pointer entirely?

> +	}
> +
> +	return rc;
>  }

[ ... ]

>  int ibmvfc_nvme_register(struct ibmvfc_host *vhost)
>  {
> +	struct nvme_fc_port_info pinfo;
> +	int rc;
> +
>  	if (!IS_ENABLED(CONFIG_NVME_FC))
>  		return 0;
>  
> -	return 0;
> +	pinfo.node_name = fc_host_node_name(vhost->host);
> +	pinfo.port_name = fc_host_port_name(vhost->host);
> +	pinfo.port_id = fc_host_port_id(vhost->host);
> +	pinfo.port_role = FC_PORT_ROLE_NVME_INITIATOR;
> +	pinfo.dev_loss_tmo = 0;
> +
> +	rc = nvme_fc_register_localport(&pinfo, &ibmvfc_nvme_fc_transport,
> +					vhost->dev, &vhost->nvme_local_port);
> +
> +	if (!rc) {
> +		ibmvfc_log(vhost, 2, "register_localport: host-traddr=nn-0x%llx:pn-0x%llx on portID:%x\n",
> +			   pinfo.node_name, pinfo.port_name, pinfo.port_id);
> +		vhost->nvme_local_port->private = vhost;

[Severity: Medium]
Similar to the remote port registration, does overwriting the pre-allocated
nvme_local_port->private pointer here orphan the core's inline buffer
allocation?

> +	} else
> +		dev_err(vhost->dev, "Failed to register NVMe fc localport (%d)\n", rc);
> +
> +	return rc;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723000149.969416-1-tyreld@linux.ibm.com?part=23