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

[Akshit Patadiya <akshit@mpiricsoftware.com>]

Hi all,

Gentle ping on this patch. When you have a chance, could you please
take a look and let me know if there are any further changes needed?

On Thu, Aug 13, 2026 at 05:19:09PM +0530, sashiko-bot@kernel.org wrote:
> [High] Concurrent updates to msk->pm.rm_list_rx can cause RM_ADDR IDs
> to be silently skipped, resulting in leaked subflows.
>
> 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

Looked into this, it's real. Traced it down:

mptcp_pm_rm_addr_recv() passes &msk->pm.rm_list_rx straight into
mptcp_pm_rm_addr_or_subflow() (pm.c:830), and that loop re-reads
rm_list->nr / rm_list->ids[i] on every iteration. It also drops
pm.lock mid-loop around mptcp_subflow_shutdown()/mptcp_close_ssk()
since those can't be called under a spinlock.

Worse, mptcp_pm_worker() clears the MPTCP_PM_RM_ADDR_RECEIVED bit
before calling mptcp_pm_rm_addr_recv():

	if (pm->status & BIT(MPTCP_PM_RM_ADDR_RECEIVED)) {
		pm->status &= ~BIT(MPTCP_PM_RM_ADDR_RECEIVED);
		mptcp_pm_rm_addr_recv(msk);
	}

so if a second RM_ADDR shows up while the first is still being
processed, mptcp_pm_schedule_work() sees the bit already clear,
treats it as new work, and mptcp_pm_rm_addr_received() overwrites
rm_list_rx right under the loop during one of its unlock windows
instead of getting coalesced. End result is the outer loop's i /
rm_list->nr can go stale mid-flight and some IDs from the original
batch just never get processed.

This is pre-existing, not something this patch touches (different
struct, different lock concern than the id_accepted_bitmap stuff
here), so I'm not folding a fix into this one. Will open a separate
issue/patch for it, can take it myself if nobody's already on it.

For #498 itself, this patch should close it as-is. It also looks
related to #496 per that issue's note - let me know if you want me
to check whether this covers that one too, or if it's a
prerequisite.

Tested against mptcp_join.sh for the close-before-RM_ADDR case,
fullmesh reuse of the same remote id, and duplicate RM_ADDR - all
passing.

Thanks and regards,
Akshit Patadiya