CVE-2026-80784: mptcp: pm: fix memory leak from alloc-during-teardown race
In the Linux kernel, the following vulnerability has been resolved:
mptcp: pm: fix memory leak from alloc-during-teardown race
mptcppmdestroy() empties msk->pm.annolist and msk->pm.userspacepmlocaladdrlist 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 mptcptokengetsock() and, in mptcppmnlannouncedoit(), calls mptcpuserspacepmappendnewlocaladdr() and mptcppmannouncedalloc(). Both take msk->pm.lock briefly to add to their respective lists. Because the genl handler holds a sock reference, mptcppmdestroy() may run on the same msk via mptcpdisconnect(), which invokes mptcpdestroycommon() without dropping the sock refcount, before the handler completes.
If the lock acquisitions interleave such that mptcppmdestroy() 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 mptcppmaddaddr objects (from mptcppmannouncedalloc()) and mptcppmaddrentry objects (from mptcpuserspacepmappendnewlocaladdr()) under sustained concurrent ANNOUNCE + close load against the userspace PM.
Add an MPTCPPMDESTROYING bit in msk->pm.status, set by mptcppmdestroy() 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 mptcppmdestroy() frees it; or mptcppmdestroy() 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).
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the leak?
A userspace path manager generic netlink ANNOUNCE operation must run concurrently with teardown of the same MPTCP socket. The race occurs when allocations are added after teardown has already emptied the corresponding path-manager list.
How can I tell whether this is occurring?
Under sustained concurrent ANNOUNCE and socket-close activity, kmemleak can report leaked mptcp_pm_add_addr objects and mptcp_pm_addr_entry objects. The affected allocations originate from mptcp_pm_announced_alloc() and mptcp_userspace_pm_append_new_local_addr().