Re: [PATCH mptcp-net] mptcp: pm: cap userspace extra_subflows at U8_MAX

[Matthieu Baerts <matttbe@kernel.org>]

Hi Quanye,

+ Cc: Tao Cui

On 02/09/2026 17:39, Quanye Yang via B4 Relay wrote:
> From: Quanye Yang <quanyeyang@proton.me>
> 
> The userspace PM increments extra_subflows with no upper bound. The
> field is a u8, so the 256th extra subflow wraps the counter to 0 and
> the next close hits WARN_ON_ONCE().
> 
> Refuse admission at U8_MAX for incoming MP_JOIN and for the Netlink
> create path.
> 
> Fixes: 77e4b94a3de6 ("mptcp: update userspace pm infos")
> Cc: stable@vger.kernel.org

(No need to add stable on patches sent to the MPTCP ML, that will be
added later when sending these patches to netdev)

> Link: https://github.com/multipath-tcp/mptcp_net-next/issues/629

"Closes:" can be used here.

(...)

> diff --git a/net/mptcp/pm_userspace.c b/net/mptcp/pm_userspace.c
> index fab16d953dbf..6d798dd96702 100644
> --- a/net/mptcp/pm_userspace.c
> +++ b/net/mptcp/pm_userspace.c
> @@ -427,16 +427,22 @@ int mptcp_pm_nl_subflow_create_doit(struct sk_buff *skb, struct genl_info *info)
>  	local.ifindex = entry.ifindex;
>  
>  	spin_lock_bh(&msk->pm.lock);
> -	msk->pm.extra_subflows++;
> -	spin_unlock_bh(&msk->pm.lock);
> +	if (msk->pm.extra_subflows == U8_MAX) {
> +		spin_unlock_bh(&msk->pm.lock);
> +		GENL_SET_ERR_MSG(info, "too many extra subflows");
> +		err = -ENOSPC;

Maybe a goto could be used here ...

> +	} else {
> +		msk->pm.extra_subflows++;
> +		spin_unlock_bh(&msk->pm.lock);
>  
> -	lock_sock(sk);
> -	err = __mptcp_subflow_connect(sk, &local, &addr_r);
> -	release_sock(sk);
> +		lock_sock(sk);
> +		err = __mptcp_subflow_connect(sk, &local, &addr_r);
> +		release_sock(sk);
> +		if (err)
> +			GENL_SET_ERR_MSG_FMT(info, "connect error: %d", err);
> +	}
>  
>  	if (err) {
> -		GENL_SET_ERR_MSG_FMT(info, "connect error: %d", err);
> -

... to here, not to modify the rest of the code?
>  		spin_lock_bh(&msk->pm.lock);
>  		mptcp_userspace_pm_delete_local_addr(msk, &entry);
>  		spin_unlock_bh(&msk->pm.lock);

This part hasn't been fixed on Tao's series [1]. Would it be OK for both
of you if this part of Quanye's patch is added to Tao's v2 series with
Quanye as author?

[1] https://lore.kernel.org/20260831093206.689827-1-cui.tao@linux.dev

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.