CVE-2026-80784 in Linux
Summary
by MITRE • 09/04/2026
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).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/05/2026
The vulnerability identified as a memory leak within the Linux kernel's Multipath TCP implementation stems from a race condition during socket teardown operations involving userspace path management handlers. Specifically, the function mptcp_pm_destroy is responsible for cleaning up address lists associated with an MPTCP subflow by emptying the anno_list and userspace_pm_local_addr_list while holding the pm.lock mutex. However, this process involves dropping and reacquiring the lock between clearing these two distinct data structures. This gap in atomicity creates a window where concurrent operations can interfere with the cleanup sequence, leading to resource leaks that persist until system reboot or module unload.
The root cause lies in the interaction between kernel-side teardown logic and userspace-generated Generic Netlink announcements. When a userspace path manager sends an ANNOUNCE message, it triggers mptcp_pm_nl_announce_doit which acquires a socket reference via mptcp_token_get_sock to ensure the socket remains alive during processing. Inside this handler, new address entries are appended to the aforementioned lists using their respective allocation functions. Because the genl handler holds a valid sock reference, the kernel may initiate mptcp_pm_destroy through an unrelated disconnect or close operation on the same MPTCP socket before the userspace handler completes its execution. This creates a scenario where both threads operate concurrently on shared data structures protected only by coarse-grained locking that is momentarily released during critical sections of the teardown process.
The operational impact manifests as a classic use-after-free avoidance failure resulting in memory leaks rather than immediate exploitation for code execution, although such races can sometimes be chained to achieve more severe outcomes depending on allocator behavior and timing. If mptcp_pm_destroy empties one list before the concurrent allocation completes its lock acquisition, the newly allocated entry is added to a list head that has already been detached from active iteration by the teardown logic. Consequently, these entries are never freed because no subsequent cleanup routine iterates over them again. This results in two types of leaked kernel objects: mptcp_pm_add_addr structures originating from announcement allocations and mptcp_pm_addr_entry structures from local address appends. Under sustained load involving concurrent ANNOUNCE messages and socket closures, this race condition causes significant memory consumption within the kernel slab allocator, potentially leading to denial of service through resource exhaustion or triggering kmemleak warnings that degrade system performance due to excessive garbage collection overhead.
To mitigate this vulnerability, a synchronization mechanism was introduced using an MPTCP_PM_DESTROYING bit flag stored in msk->pm.status. This flag is set by mptcp_pm_destroy while holding pm.lock prior to emptying the lists. Concurrent allocation paths now check for this status bit under the protection of pm.lock before attempting to append new entries. This ensures mutual exclusion at a logical level: either the allocation completes and adds its entry to the list before destruction begins, allowing it to be properly freed during teardown; or the destruction process takes precedence by setting the flag first, causing subsequent allocations to detect the state and refuse to add entries that would otherwise leak. This approach eliminates the race window without requiring complex lock restructuring, maintaining system stability while ensuring all allocated resources are correctly tracked and released.
From a classification perspective, this vulnerability aligns with CWE-401 Missing Release of Memory after Effective Lifetime which describes situations where memory is not freed properly leading to resource exhaustion. The underlying technical flaw involves improper synchronization in concurrent access scenarios characteristic of CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization Race Condition. In terms of attack vector and behavior, this relates to ATT&CK technique T1496 Resource Hijacking where an attacker could potentially exhaust system resources through sustained triggering of the race condition, although primarily it represents a reliability issue rather than direct privilege escalation or data exfiltration path in standard configurations. The fix demonstrates best practices for handling concurrent kernel operations by utilizing status flags protected by existing locks to serialize access patterns effectively during critical lifecycle transitions like socket destruction.