This reverts commit c577ab7ba5f3bf9062db8a58b6e89d4fe370447e.

The invocation of iscsi_put_conn() in iscsi_iter_destory_conn_fn() is used
to free the initial reference counter of iscsi_cls_conn.
For non-qla4xxx cases, the ->destroy_conn() callback (e.g.,
iscsi_conn_teardown) will call iscsi_remove_conn() and iscsi_put_conn() to
remove the connection from the children list of session and free the
connection at last.
However for qla4xxx, it is not the case. The ->destroy_conn() callback
of qla4xxx will keep the connection in the session conn_list and doesn't
use iscsi_put_conn() to free the initial reference counter. Therefore,
it seems necessary to keep the iscsi_put_conn() in the
iscsi_iter_destroy_conn_fn(), otherwise, there will be memory leak
problem.

Link: https://lore.kernel.org/all/88334658-072b-4b90-a949-9c74ef93cfd1@huawei.com/
Fixes: c577ab7ba5f3 ("scsi: iscsi: Fix HW conn removal use after free")
Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com>
---
 drivers/scsi/scsi_transport_iscsi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/scsi/scsi_transport_iscsi.c b/drivers/scsi/scsi_transport_iscsi.c
index c75a806496d6..743b4c792ceb 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -2143,6 +2143,8 @@ static int iscsi_iter_destroy_conn_fn(struct device *dev, void *data)
 		return 0;
 
 	iscsi_remove_conn(iscsi_dev_to_conn(dev));
+	iscsi_put_conn(iscsi_dev_to_conn(dev));
+
 	return 0;
 }
 
-- 
2.46.1

Li,

> This reverts commit c577ab7ba5f3bf9062db8a58b6e89d4fe370447e.

Applied to 6.17/scsi-staging, thanks!

-- 
Martin K. Petersen

On 7/15/25 2:39 AM, Li Lingfeng wrote:
> This reverts commit c577ab7ba5f3bf9062db8a58b6e89d4fe370447e.
> 
> The invocation of iscsi_put_conn() in iscsi_iter_destory_conn_fn() is used
> to free the initial reference counter of iscsi_cls_conn.
> For non-qla4xxx cases, the ->destroy_conn() callback (e.g.,
> iscsi_conn_teardown) will call iscsi_remove_conn() and iscsi_put_conn() to
> remove the connection from the children list of session and free the
> connection at last.
> However for qla4xxx, it is not the case. The ->destroy_conn() callback
> of qla4xxx will keep the connection in the session conn_list and doesn't
> use iscsi_put_conn() to free the initial reference counter. Therefore,
> it seems necessary to keep the iscsi_put_conn() in the
> iscsi_iter_destroy_conn_fn(), otherwise, there will be memory leak
> problem.
> 
I must have thought we did a unregister instead of remove for
some reason. Thanks for catching this.

Reviewed-by: Mike Christie <michael.christie@oracle.com>

Hi, Mike

在 2025/7/18 4:01, Mike Christie 写道:
> On 7/15/25 2:39 AM, Li Lingfeng wrote:
>> This reverts commit c577ab7ba5f3bf9062db8a58b6e89d4fe370447e.
>>
>> The invocation of iscsi_put_conn() in iscsi_iter_destory_conn_fn() is used
>> to free the initial reference counter of iscsi_cls_conn.
>> For non-qla4xxx cases, the ->destroy_conn() callback (e.g.,
>> iscsi_conn_teardown) will call iscsi_remove_conn() and iscsi_put_conn() to
>> remove the connection from the children list of session and free the
>> connection at last.
>> However for qla4xxx, it is not the case. The ->destroy_conn() callback
>> of qla4xxx will keep the connection in the session conn_list and doesn't
>> use iscsi_put_conn() to free the initial reference counter. Therefore,
>> it seems necessary to keep the iscsi_put_conn() in the
>> iscsi_iter_destroy_conn_fn(), otherwise, there will be memory leak
>> problem.
>>
> I must have thought we did a unregister instead of remove for
> some reason. Thanks for catching this.
Just wanted to check – do you still have the original diagnostic
information/data from the UAF issue? Since we're reverting the patch,
perhaps we should revisit the root cause to determine the most
appropriate fix approach.

Thanks,

Lingfeng

>
> Reviewed-by: Mike Christie <michael.christie@oracle.com>
>