CVE-2026-80784

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.userspacepmlocaladdr_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 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 mptcpdestroy_common() 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 mptcpuserspacepmappendnewlocal_addr()) 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).