Re: [PATCH 05/20] scsi: ibmvfc: fix uninitialized _done dereference for TMF events on send failure

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] scsi: ibmvfc: FCP TMF send failures silently report false success
--

commit c0038842ca930b0a5898cd284c6625f6e31cea8f
Author: Tyrel Datwyler <tyreld@linux.ibm.com>

scsi: ibmvfc: fix uninitialized _done dereference for TMF events on send failure

This commit fixes a wild function-pointer dereference in ibmvfc_send_event()
by restricting the _done reassignment to IBMVFC_MAD_FORMAT events only. FCP
Task Management Function (TMF) events will no longer reach this branch.

> 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
> @@ -1859,7 +1859,7 @@ int ibmvfc_send_event(struct ibmvfc_event *evt,
>  			evt->done = ibmvfc_vfc_eh_done;
>  		} else if (evt->fcp_req || evt->ls_req) {
>  			evt->done = ibmvfc_vfc_eh_done;
> -		} else {
> +		} else if (evt->crq.format == IBMVFC_MAD_FORMAT) {
>  			evt->xfer_iu->mad_common.status = cpu_to_be16(IBMVFC_MAD_CRQ_ERROR);
>  			evt->done = evt->_done;
>  		}

[Severity: High]
Does skipping this branch for FCP TMF events (which use IBMVFC_CMD_FORMAT)
inadvertently cause send failures to be reported as successes?

If ibmvfc_send_event() fails and we bypass this assignment, the
zero-initialized FCP command status in evt->xfer_iu->cmd.status remains
unmodified before evt->done(evt) is called.

Callers like ibmvfc_reset_device() appear to check this zero status and
falsely assume the operation succeeded:

ibmvfc_reset_device()
    ...
    if (rsp_iu.cmd.status)
        rsp_code = ibmvfc_get_err_result(vhost, &rsp_iu.cmd);

The same pattern appears in ibmvfc_eh_abort_handler(), which also checks
the unmodified status:

ibmvfc_eh_abort_handler()
    ...
    if (rsp_iu.cmd.status)
        rsp_code = ibmvfc_get_err_result(vhost, &rsp_iu.cmd);

Will this lead to the SCSI midlayer receiving false success reports when
TMF resets or aborts fail to send during SAN error conditions?

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