Re: [PATCH mptcp-next] mptcp: fix add_addr_accepted accounting on subflow close

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

Pre-existing issues:
- [High] Concurrent updates to msk->pm.rm_list_rx can cause RM_ADDR IDs to be silently skipped, resulting in leaked subflows.
--

--- Patch [1]: [PATCH mptcp-next] mptcp: fix add_addr_accepted accounting on subflow close ---
commit 09eae8ab35dfee45655629d4bbc00b4a93d797f3
Author: Akshit Patadiya <[email protected]>

mptcp: fix add_addr_accepted accounting on subflow close

When an accepted remote address is used by a subflow that is closed before
the corresponding RM_ADDR is received, the add_addr_accepted counter is not
decremented. This commit releases the accepted-address slot when the subflow
closes, allowing subsequent ADD_ADDR requests to reuse the budget.

Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/498

> diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c
> --- a/net/mptcp/pm.c
> +++ b/net/mptcp/pm.c
[ ... ]
> @@ -786,7 +788,6 @@ static void mptcp_pm_rm_addr_or_subflow(struct mptcp_sock *msk,
>  
>  	for (i = 0; i < rm_list->nr; i++) {
>  		u8 rm_id = rm_list->ids[i];
> -		bool removed = false;
>  
>  		mptcp_for_each_subflow_safe(msk, subflow, tmp) {
>  			struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
> @@ -807,7 +808,6 @@ static void mptcp_pm_rm_addr_or_subflow(struct mptcp_sock *msk,
>  				 i, rm_id, id, remote_id, msk->mpc_endpoint_id);
>  			spin_unlock_bh(&msk->pm.lock);
>  			mptcp_subflow_shutdown(sk, ssk, how);

[Severity: High]
This isn't a bug introduced by this patch, but could this loop miss RM_ADDR 
IDs and leak subflows due to concurrent list updates?

In mptcp_pm_rm_addr_or_subflow(), this loop iterates over the rm_list (which 
is passed as &msk->pm.rm_list_rx) and temporarily drops pm->lock around 
mptcp_subflow_shutdown().

If a remote peer sends multiple RM_ADDR options in rapid succession, softirq 
context can call mptcp_pm_rm_addr_received(), which unconditionally overwrites 
pm->rm_list_rx while scheduling work:

net/mptcp/pm.c:mptcp_pm_rm_addr_received() {
    ...
    if (mptcp_pm_schedule_work(msk, MPTCP_PM_RM_ADDR_RECEIVED))
        pm->rm_list_rx = *rm_list;
    ...
}

If pm->rm_list_rx is overwritten mid-iteration while the worker thread dropped 
pm->lock, wouldn't the loop in mptcp_pm_rm_addr_or_subflow() either terminate 
early or read incorrect indices from the new list, silently skipping unhandled 
IDs from the original list and leaking the associated resources?

> -			removed |= subflow->request_join;
>  
>  			/* the following takes care of updating the subflows counter */
>  			mptcp_close_ssk(sk, ssk, subflow);
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1