Cloudanix VulnDB

CVE-2026-80784

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's multipath TCP code can slowly leak memory when many connections are opened and closed at the same time, eventually affecting system stability.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race during mptcp_pm_destroy() list emptying and concurrent userspace PM ANNOUNCE allocations allows mptcp_pm_add_addr and mptcp_pm_addr_entry objects to be added to lists that are never subsequently iterated, producing a permanent kernel memory leak.

Why it matters to the business

Sustained MPTCP socket churn combined with userspace path-manager ANNOUNCE operations can gradually exhaust kernel memory, degrading or crashing affected systems that rely on MPTCP for multipath transport.

How an attack unfolds

An attacker or workload triggers repeated netlink ANNOUNCE operations via the userspace PM while simultaneously forcing MPTCP socket teardown (e.g., via mptcp_disconnect or close), interleaving lock acquisitions so that allocations occur after the destroy path has already emptied the lists, leaving orphaned objects that kmemleak later reports.

How to fix it

Apply the upstream kernel patch that introduces the MPTCP_PM_DESTROYING status bit, set under pm.lock before list emptying and checked by allocation paths; rebuild and deploy the fixed kernel on all systems using MPTCP with userspace PM.

How to confirm the fix worked

Confirm the MPTCP_PM_DESTROYING bit and associated checks are present in mptcp_pm.c; run the BRF-based MPTCP protocol-flow harness under concurrent ANNOUNCE+close load and verify kmemleak reports no new mptcp_pm_add_addr or mptcp_pm_addr_entry leaks.

Typical attack path

  1. Obtain or create an MPTCP socket configured for userspace path management
  2. Issue concurrent MPTCP_PM_CMD_ANNOUNCE netlink messages while triggering socket close or disconnect
  3. Exploit the window between msk->pm.lock releases in mptcp_pm_destroy to allocate entries after lists have been cleared
  4. Repeat under load until memory pressure becomes noticeable or kmemleak reports leaks

How to detect it

Inspect kmemleak output for unreferenced mptcp_pm_add_addr and mptcp_pm_addr_entry objects; correlate with netlink audit logs showing MPTCP_PM_CMD_ANNOUNCE messages occurring near socket close events on the same MPTCP socket.

  • mptcp_pm_add_addr
  • mptcp_pm_addr_entry
  • MPTCP_PM_DESTROYING
  • mptcp_pm_nl_announce_doit

What your security team should do

  • Prioritize patching MPTCP-enabled kernels that expose userspace PM netlink interfaces
  • Monitor kernel memory usage and kmemleak output on systems performing frequent MPTCP socket turnover
  • Temporarily disable userspace path manager if patching is delayed and workload permits

The record

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

Affected packages

Ecosystem Package Introduced Fixed