Re: [PATCH net v1] net/smc: fix socket use-after-free during link group termination

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Socket reference count leak in smc_switch_conns() error path.
- [High] Concurrent execution of smc_close_active_abort() and smc_clcsock_release() can lead to a TOCTOU NULL pointer dereference or Use-After-Free.
--

--- Patch [1]: [PATCH net v1] net/smc: fix socket use-after-free during link group termination ---
commit d8af9113083c00ced5108b5d3f34199756d886c8
Author: Xuanqiang Luo <luoxuanqiang@kylinos.cn>

net/smc: fix socket use-after-free during link group termination

This patch fixes a socket use-after-free in __smc_lgr_terminate() by
taking a reference on the socket while the link group connection lock
is still held.

> diff --git a/net/smc/smc_core.c b/net/smc/smc_core.c
> index cf6b620fef05f..b4208cb186c5e 100644
> --- a/net/smc/smc_core.c
> +++ b/net/smc/smc_core.c
> @@ -1572,10 +1572,10 @@ static void __smc_lgr_terminate(struct smc_link_group *lgr, bool soft)
>  	read_lock_bh(&lgr->conns_lock);
>  	node = rb_first(&lgr->conns_all);
>  	while (node) {
> -		read_unlock_bh(&lgr->conns_lock);
>  		conn = rb_entry(node, struct smc_connection, alert_node);
>  		smc = container_of(conn, struct smc_sock, conn);
>  		sock_hold(&smc->sk); /* sock_put below */
> +		read_unlock_bh(&lgr->conns_lock);
>  		lock_sock(&smc->sk);
>  		smc_conn_kill(conn, soft);

[Severity: High]
This is a pre-existing issue, but I noticed a potential race condition
involving smc_close_active_abort() when called via smc_conn_kill() from here.

Does this code risk a use-after-free if smc_clcsock_release() is running
concurrently?

When another thread runs __smc_release(), it explicitly drops the socket lock
before calling smc_clcsock_release():

net/smc/af_smc.c:__smc_release() {
			release_sock(sk);
			smc_clcsock_release(smc);
			lock_sock(sk);
}

This allows smc_close_active_abort() to run concurrently and dereference
smc->clcsock without holding the clcsock_release_lock:

net/smc/smc_close.c:smc_close_active_abort() {
	if (sk->sk_state != SMC_INIT && smc->clcsock && smc->clcsock->sk) {
		sk->sk_err = ECONNABORTED;
		if (smc->clcsock && smc->clcsock->sk)
			tcp_abort(smc->clcsock->sk, ECONNABORTED);
	}
}

If smc_clcsock_release() zeroes and frees the underlying TCP socket at the
exact same time, could passing smc->clcsock->sk to tcp_abort() crash?

>  		release_sock(&smc->sk);

[ ... ]

While reviewing the above, I also noticed another pre-existing issue in the
same file.

[Severity: High]
This isn't a bug introduced by this patch, but does the error path in
smc_switch_conns() leak a socket reference?

The loop acquires a socket reference to protect it across the sleepable
buffer fetch:

net/smc/smc_core.c:smc_switch_conns() {
		sock_hold(&smc->sk);
...
		if (rc)
			goto err_out;
}

However, the err_out label completely lacks the corresponding sock_put()
cleanup to balance the reference:

net/smc/smc_core.c:smc_switch_conns() {
err_out:
	smcr_link_down_cond_sched(to_lnk);
	smc_wr_tx_link_put(to_lnk);
	return NULL;
}

Could this cause memory exhaustion over time if a connection switch fails?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723105454.87016-1-xuanqiang.luo@linux.dev?part=1