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

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

[WenTao Liang]

In mpt3sas_transport_port_add(), after acquiring the sas_device by
calling mpt3sas_get_sdev_by_addr() (which bumps the reference count via
sas_device_get()), several error paths leak the reference.  If
sas_node->parent_dev is NULL, or port creation/sas_port_add() fails, or
rphy allocation or sas_rphy_add() fails, the function jumps to out_fail
or out_delete_port, where the sas_device reference is not released.  The
reference is only dropped on the success path via sas_device_put().

Add the missing sas_device_put() call in the out_fail cleanup, which
also covers the out_delete_port label that falls through to out_fail.
This fixes the leak for all error paths that occur after the sas_device
is acquired.  Before that point, sas_device is NULL, so the put is safe.

Cc: stable@vger.kernel.org
Fixes: f92363d12359 ("[SCSI] mpt3sas: add new driver supporting 12GB SAS")
Signed-off-by: WenTao Liang <vulab@iscas.ac.cn>
---
 drivers/scsi/mpt3sas/mpt3sas_transport.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_transport.c b/drivers/scsi/mpt3sas/mpt3sas_transport.c
index e74a526efa8d..f831d4823503 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);
+	if (sas_device)
+		sas_device_put(sas_device);
 	kfree(mpt3sas_port);
 	return NULL;
 }
-- 
2.50.1 (Apple Git-155)

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

[sashiko-bot]

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