Re: [PATCH] scsi: mpt3sas: fix refcount leak in mpt3sas_transport_port_add()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] The `phy_belongs_to_port` flag is left set to 1 on PHY objects if the port addition fails midway, permanently orphaning the phys.
- [Medium] The allocated `struct sas_port` object is leaked if `sas_port_add()` fails.
--

commit 9f7a04ec16ac25a146b4b86266e9c7e403ae4717
Author: WenTao Liang <vulab@iscas.ac.cn>

scsi: mpt3sas: fix refcount leak in mpt3sas_transport_port_add()

In mpt3sas_transport_port_add(), after acquiring the sas_device by
calling mpt3sas_get_sdev_by_addr(), several error paths leak the reference.

> diff --git a/drivers/scsi/mpt3sas/mpt3sas_transport.c b/drivers/scsi/mpt3sas/mpt3sas_transport.c
> index e74a526efa8db..f831d48235031 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_transport.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_transport.c
> @@ -869,6 +869,8 @@ mpt3sas_transport_port_add(struct MPT3SAS_ADAPTER *ioc, u16 handle,
>  	list_for_each_entry_safe(mpt3sas_phy, next, &mpt3sas_port->phy_list,
>  	    port_siblings)
>  		list_del(&mpt3sas_phy->port_siblings);

[Severity: Medium]
This is a pre-existing issue, but does this error path leak the sas_port
object? 

If sas_port_add(port) fails earlier in mpt3sas_transport_port_add(), the code
jumps here to the out_fail label. It looks like sas_port_free(port) needs
to be called to release the un-added object and its underlying device, but
it appears to be missing from this cleanup block.

[Severity: High]
This is a pre-existing issue, but is the phy_belongs_to_port flag left in
an incorrect state on failure?

Earlier in mpt3sas_transport_port_add(), the phys are added to the port:

    sas_port_add_phy(port, mpt3sas_phy->phy);
    mpt3sas_phy->phy_belongs_to_port = 1;

If a subsequent operation like sas_rphy_add() fails, the code falls through to
this block. The phys are removed from mpt3sas_port->phy_list via list_del(),
but the phy_belongs_to_port flag remains set to 1.

Since these phys reside in the persistent sas_node->phy[] array, will they
be permanently ignored during future discovery or port addition attempts
because the flag was not reverted to 0?

> +	if (sas_device)
> +		sas_device_put(sas_device);
>  	kfree(mpt3sas_port);
>  	return NULL;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260611084324.70303-1-vulab@iscas.ac.cn?part=1