Re: [PATCH net v2] mptcp: pm: fix memory leak from alloc-during-teardown race

[Matthieu Baerts <matttbe@kernel.org>]

Hi Shardul,

Thank you for the v2!

On 24/05/2026 07:29, Shardul Bankar wrote:
> mptcp_pm_destroy() drains msk->pm.anno_list via list_splice_init()
> under msk->pm.lock and then, for the userspace PM, drains
> msk->pm.userspace_pm_local_addr_list under the same lock. Between
> the two splices, msk->pm.lock is released.
> 
> A concurrent userspace PM genl ANNOUNCE on the same msk holds a
> sock reference via mptcp_token_get_sock() and, in
> mptcp_pm_nl_announce_doit(), calls
> mptcp_userspace_pm_append_new_local_addr() and
> mptcp_pm_alloc_anno_list(). Both take msk->pm.lock briefly to
> add to their respective lists. Because the genl handler holds a
> sock reference, mptcp_pm_destroy() may run on the same msk via
> mptcp_disconnect(), which invokes mptcp_destroy_common() without
> dropping the sock refcount, before the handler completes.
> 
> If the lock acquisitions interleave such that mptcp_pm_destroy()'s
> splice runs first, the subsequent alloc paths land on a list head
> pointing to itself. Nothing else iterates that list for this msk,
> and the added entry leaks. kmemleak reports both 192-byte
> mptcp_pm_add_entry objects (from mptcp_pm_alloc_anno_list()) and
> 64-byte mptcp_pm_addr_entry objects (from
> mptcp_userspace_pm_append_new_local_addr()) under sustained
> concurrent ANNOUNCE + close load against the userspace PM.
> 
> Add an MPTCP_PM_DESTROYING bit in msk->pm.status, set by
> mptcp_pm_destroy() under pm.lock before the splice and checked
> under pm.lock by the alloc paths. Either the alloc takes pm.lock
> first, in which case its entry will be on the list when destroy's
> splice runs and will be freed normally; or destroy takes pm.lock
> first, in which case the subsequent alloc observes the bit and
> refuses. Either ordering is correct, and the race that orphans
> an entry is precluded. The bit lives in the pm data reset group,
> so mptcp_pm_data_reset() clears it on the disconnect/reuse path
> as well as on fresh socket init.
> 
> Found by an MPTCP protocol-flow harness extending BRF
> (arXiv:2305.08782). Baseline ~0.3 kmemleak reports/minute on the
> userspace PM reduces to zero across multi-hour runs with this
> patch applied.

I guess you also validated the v2 against your reproducer, right?

I'm asking, because sashiko thinks there is still a way to hit the issue
if the userspace does a shutdown() (mptcp_disconnect()):

https://sashiko.dev/#/patchset/20260523212930.2957096-1-shardul.b@mpiricsoftware.com

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