Re: [PATCH mptcp-net v3] mptcp: pm: userspace: unify entry free path via RCU callback

Hi Geliang, Mat,

On 01/07/2026 08:11, Geliang Tang wrote:
> From: Geliang Tang <[email protected]>
> 
> In mptcp_pm_nl_remove_doit(), sk_omem_alloc is decremented immediately
> but the memory is freed later via kfree_rcu(). This allows a CAP_NET_ADMIN
> user to bypass the socket memory quota and exhaust kernel memory by
> accumulating RCU callbacks.
> 
> Fix by using call_rcu() with a custom callback that uses sock_kfree_s()
> to free the entry and decrement sk_omem_alloc atomically. To ensure the
> socket remains valid until the callback runs, take a reference with
> sock_hold() when storing the socket pointer in the entry, and release it
> with sock_put() in the callback.
> 
> Convert the synchronous freeing paths in free_local_addr_list() and
> delete_local_addr() to use the same RCU callback, ensuring the socket
> reference is properly released.
> 
> Additionally, mptcp_userspace_pm_append_new_local_addr() now checks
> SOCK_DEAD under the spinlock before allocating. A SYN+JOIN handler
> holding an msk reference from mptcp_token_get_sock() could otherwise
> race with __mptcp_destroy_sock() - sock_orphan() sets SOCK_DEAD and
> then mptcp_userspace_pm_release() clears the list, so a new entry
> allocated after that point would never be freed and its sock_hold()
> would leak the msk permanently.

Thank you for this patch, and your patience!

It looks OK to me, but TBH, I'm not confident enough to judge if this is
the best way to address this issue, plus if this issue mentioned by
Sashiko [1] can really be observed. By chance, do you have any
reproducer for the original issue?

@Mat: WDYT?

Also, after "mptcp: pm: userspace: properly handle the ID0 case" [2], I
guess we will need a sock_hold() in mptcp_pm_userspace_created as well.

[1]
https://sashiko.dev/#/patchset/[email protected]
[2]
https://lore.kernel.org/20260807-mptcp-pm-userspace-id0-case-v3-1-de9088549924@kernel.org

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