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).