CVE-2026-80784

In the Linux kernel, the following vulnerability has been resolved:

mptcp: pm: fix memory leak from alloc-during-teardown race

mptcp_pm_destroy() empties msk->pm.anno_list and

msk->pm.userspace_pm_local_addr_list under msk->pm.lock during socket

teardown, dropping the lock between the two.

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_announced_alloc(). 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() empties

a list first, the later alloc adds its entry to a list head that nothing

else iterates for this msk, and the entry leaks. kmemleak reports both

mptcp_pm_add_addr objects (from mptcp_pm_announced_alloc()) and

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 lists are emptied and

checked under pm.lock by the alloc paths. Either the alloc takes pm.lock

first, in which case its entry is on the list when mptcp_pm_destroy()

frees it; or mptcp_pm_destroy() takes pm.lock first, in which case the

later alloc observes the bit and refuses.

Found by an MPTCP protocol-flow harness extending BRF (arXiv:2305.08782).