All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ye Bin" <yebin@huaweicloud.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH -next 1/2] scsi: iscsi: fix NULL pointer dereference in iscsi_sw_tcp_release_conn()
Date: Fri, 21 Aug 2026 09:47:56 +0000	[thread overview]
Message-ID: <20260821094757.45F171F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260821092435.1632931-2-yebin@huaweicloud.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch introduces an endpoint (`struct iscsi_endpoint`) reference leak by unconditionally clearing `ISCSI_CLS_CONN_BIT_CLEANUP` in `iscsi_if_stop_conn()` during a `STOP_CONN_TERM`, causing the subsequent endpoint disconnect to incorrectly skip releasing the workqueue's reference.
--

--- Patch [1]: [PATCH -next 1/2] scsi: iscsi: fix NULL pointer dereference in iscsi_sw_tcp_release_conn() ---
commit 15cab28507a9da46dab7d098d970770bae480083
Author: Ye Bin <yebin10@huawei.com>

scsi: iscsi: fix NULL pointer dereference in iscsi_sw_tcp_release_conn()

This commit addresses a NULL pointer dereference in iscsi_sw_tcp_release_conn()
by ensuring the ISCSI_CLS_CONN_BIT_CLEANUP bit is set during STOP_CONN_TERM.
This prevents concurrent execution of iscsi_stop_conn().

> diff --git a/drivers/scsi/scsi_transport_iscsi.c b/drivers/scsi/scsi_transport_iscsi.c
> index 8aa76f813bcdb..aea319c1e72fe 100644
> --- a/drivers/scsi/scsi_transport_iscsi.c
> +++ b/drivers/scsi/scsi_transport_iscsi.c
> @@ -2278,35 +2280,36 @@ static int iscsi_if_stop_conn(struct iscsi_cls_conn *conn, int flag)

[ ... ]

> -		/*
> -		 * Only clear for recovery to avoid extra cleanup runs during
> -		 * termination.
> -		 */
> -		spin_lock_irq(&conn->lock);
> -		clear_bit(ISCSI_CLS_CONN_BIT_CLEANUP, &conn->flags);
> -		spin_unlock_irq(&conn->lock);
> -	}
> +	} else {
> +		iscsi_stop_conn(conn, flag);
> +	}
> +
> +	spin_lock_irq(&conn->lock);
> +	clear_bit(ISCSI_CLS_CONN_BIT_CLEANUP, &conn->flags);
> +	spin_unlock_irq(&conn->lock);

[Severity: High]
Does this unconditionally clear ISCSI_CLS_CONN_BIT_CLEANUP during
STOP_CONN_TERM?

The original code avoided clearing this bit during termination, as the removed
comment explicitly noted.

If a connection error queues iscsi_cleanup_conn_work_fn(), which unbinds the
endpoint (setting conn->ep = NULL), and then userspace initiates termination
via iscsi_if_stop_conn(conn, STOP_CONN_TERM), iscsi_if_disconnect_bound_ep()
won't be called here because conn->ep is NULL.

When this bit is subsequently cleared unconditionally, and userspace later issues
an event to disconnect the endpoint, will iscsi_if_disconnect_bound_ep() skip
releasing the workqueue's reference?

drivers/scsi/scsi_transport_iscsi.c:iscsi_if_disconnect_bound_ep() {
    ...
	if (!test_bit(ISCSI_CLS_CONN_BIT_CLEANUP, &conn->flags)) {
		spin_unlock_irq(&conn->lock);
		iscsi_ep_disconnect(conn, is_active);
	} else {
		...
		iscsi_put_endpoint(ep);
    ...
}

Could this cause a resource leak of struct iscsi_endpoint over time?

> +
>  	ISCSI_DBG_TRANS_CONN(conn, "iscsi if conn stop done.\n");
>  	return 0;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260821092435.1632931-1-yebin@huaweicloud.com?part=1

  reply	other threads:[~2026-08-21  9:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-21  9:24 [PATCH -next 0/2] scsi: iscsi: Fix races in connection cleanup path Ye Bin
2026-08-21  9:24 ` [PATCH -next 1/2] scsi: iscsi: fix NULL pointer dereference in iscsi_sw_tcp_release_conn() Ye Bin
2026-08-21  9:47   ` sashiko-bot [this message]
2026-08-21  9:24 ` [PATCH -next 2/2] scsi: iscsi: Fix use-after-free in iscsi_conn_release() for cleanup_work Ye Bin
2026-08-21  9:49   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260821094757.45F171F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=yebin@huaweicloud.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.