Re: [PATCH net v3] net/smc: fix out-of-bounds read when sk_user_data holds a sk_psock

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] Unconditional overwrite of sk_user_data during SMC fallback causes sk_psock memory leak and critical type confusion (control flow hijack).
--

commit c092e3d84654761aba7753030c182ca2840fc519
Author: Sechang Lim <rhkrqnwk98@gmail.com>

net/smc: fix out-of-bounds read when sk_user_data holds a sk_psock

A passive-open child inherits the listener's smc_clcsock_data_ready callback.
This commit reserves the child's sk_user_data with a NULL pointer tagged
SK_USER_DATA_NOCOPY to prevent sockmap from claiming the slot, and releases
it at accept.

> diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
> index b5db69073e20f..78f162344fe3a 100644
> --- a/net/smc/af_smc.c
> +++ b/net/smc/af_smc.c

[ ... ]

> @@ -1786,6 +1791,9 @@ static int smc_clcsock_accept(struct smc_sock *lsmc, struct smc_sock **new_smc)
>  		if (lsmc->clcsk_error_report)
>  			new_clcsock->sk->sk_error_report = lsmc->clcsk_error_report;
>  	}
> +	/* release the slot reserved in smc_tcp_syn_recv_sock() */
> +	rcu_assign_sk_user_data(new_clcsock->sk, NULL);

[Severity: Critical]
This is a pre-existing issue, but does clearing this reservation to NULL
explicitly re-open the window for a BPF sockmap program to attach to the
socket during the subsequent SMC handshake?

If a BPF SOCK_OPS program attaches the established TCP socket to a sockmap,
sk_psock_init() can set sk_user_data to a new sk_psock and hijack the socket
callbacks. Should the SMC handshake fail and fall back to TCP, the fallback
path appears to blindly overwrite sk_user_data:

net/smc/af_smc.c:smc_fback_replace_callbacks() {
        ...
        write_lock_bh(&clcsk->sk_callback_lock);
        __rcu_assign_sk_user_data_with_flags(clcsk, smc, SK_USER_DATA_NOCOPY);
        ...
}

Can this lead to a type confusion if the hijacked sockmap callbacks are left
active? When TCP data arrives, smc_fback_data_ready would forward to the
sockmap callback which dereferences sk_user_data expecting a struct sk_psock,
but receives a struct smc_sock instead.

> +	write_unlock_bh(&new_clcsock->sk->sk_callback_lock);
>  
>  	(*new_smc)->clcsock = new_clcsock;
>  out:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629095140.679754-1-rhkrqnwk98@gmail.com?part=1