Re: [PATCH v2 18/33] ibmvfc: add NVMe/FC Process Login support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Missing protocol validation in PRLI response handling allows protocol mismatch between target and response.
--

--- Patch [18]: [PATCH v2 18/33] ibmvfc: add NVMe/FC Process Login support ---
commit 6682b3a365a88d88e3d8b2117f28f9fba600bb88
Author: Tyrel Datwyler <tyreld@linux.ibm.com>

ibmvfc: add NVMe/FC Process Login support

This commit extends the PRLI handling code in the ibmvfc driver to
support NVMe/FC targets. It issues the NVMe process login MAD when the
target protocol is NVMe/FC, sets the NVMe FC-4 type, and populates the
service parameters, subsequently decoding them to assign the proper
remote-port roles.

> diff --git a/drivers/scsi/ibmvscsi/ibmvfc-core.c b/drivers/scsi/ibmvscsi/ibmvfc-core.c
> --- a/drivers/scsi/ibmvscsi/ibmvfc-core.c
> +++ b/drivers/scsi/ibmvscsi/ibmvfc-core.c
[ ... ]
> @@ -4110,6 +4111,22 @@ static void ibmvfc_tgt_prli_done(struct ibmvfc_event *evt)
>  				ibmvfc_retry_tgt_init(tgt, ibmvfc_tgt_send_prli);
>  			else
>  				ibmvfc_del_tgt(tgt);
> +		} else if (parms->type == IBMVFC_NVME_FCP_TYPE) {
> +			if (prli_rsp[index].logged_in) {
> +				/* For FC-NVMe PRLI the Image Pair field is always set to zero (see 6.3.3) */
> +				tgt->need_login = 0;
> +				tgt->ids.roles = 0;
> +				if (be32_to_cpu(parms->service_parms) & IBMVFC_PRLI_NVME_TARGET)
> +					tgt->ids.roles |= FC_PORT_ROLE_NVME_TARGET;
> +				if (be32_to_cpu(parms->service_parms) & IBMVFC_PRLI_NVME_INITIATOR)
> +					tgt->ids.roles |= FC_PORT_ROLE_NVME_INITIATOR;
> +				if (be32_to_cpu(parms->service_parms) & IBMVFC_PRLI_NVME_DISCOVERY)
> +					tgt->ids.roles |= FC_PORT_ROLE_NVME_DISCOVERY;
> +				tgt->add_rport = 1;

[Severity: Medium]
Does this code allow a protocol mismatch if the target returns an unexpected
FC-4 type in the PRLI response?

In ibmvfc_tgt_prli_done(), the response is evaluated purely based on
parms->type without checking if it matches the expected tgt->protocol.

If a target responds to a SCSI PRLI (where tgt->protocol is
IBMVFC_PROTO_SCSI) with the NVMe type (IBMVFC_NVME_FCP_TYPE), would the
driver branch into this NVMe handling block?

This appears to allow registering an FC remote port with the wrong transport
roles if a buggy or malicious target returns a mismatched response type.

> +			} else if (prli_rsp[index].retry)
> +				ibmvfc_retry_tgt_init(tgt, ibmvfc_tgt_send_prli);
> +			else
> +				ibmvfc_del_tgt(tgt);
>  		} else
>  			ibmvfc_del_tgt(tgt);
>  		break;

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