A subtle correctness bug in the Linux kernel's Multipath TCP (MPTCP) path‑manager was fixed this year after selftests and syzbot triggered a counter underflow and related warnings that can lead to sustained availability loss for hosts that use MPTCP — tracked as CVE‑2024‑45010 and fixed in the stable kernels listed below.
Multipath TCP (MPTCP) is a kernel‑level extension to TCP that lets a single logical connection use multiple network interfaces or paths simultaneously. That capability is increasingly used in mobile devices, link‑aggregation scenarios, and cloud‑native networking stacks where path diversity improves throughput and resilience. Because MPTCP touches low‑level socket and path management logic, kernel bugs in MPTCP have immediate consequences for connection stability and host availability.
In September 2024 maintainers merged a small but important patch to the MPTCP path‑manager that addresses incorrect bookkeeping when endpoints are removed. The problem showed up during the "remove single address" and related MPTCP selftests: the code could mark the wrong type of endpoint as having freed an address ID and then decrement an internal counter that tracks how many local addresses are in use. That mismatch could drive the counter negative or otherwise desynchronize accounting, producing WARN_ON_ONCE messages and enabling crash or availability conditions in the MPTCP management path.
Why this matters: incorrect accounting in a kernel networking stack can cascade. If an ID is marked available when it is in use, later operations may allocate or free resources improperly; if counters are decremented incorrectly, re‑addition of addresses can be misrouted or refused, and in the worst case use‑after‑free or assertion paths may trigger panics, oopses, or a kernel crash — all resulting in loss of availability for networking services. Multiple vendors flagged the impact as an availability risk.
Note: the vulnerability requires local privileges (low privilege required), so remote attackers cannot exploit this over the network unless they already have a local ability to submit the specific MPTCP operations (for example, via a local process or a compromised container). That said, the availability impact is real: an attacker who can exercise the MPTCP netlink interfaces or cause the kernel to process the offending path‑manager sequences can cause sustained or persistent denial‑of‑service on MPTCP‑using hosts.
Developers added a defensive check (WARN_ON_ONCE) to expose the pathological condition during testing, then updated the code so the local_addr_used counter is only decremented when the removal is operating on a true subflow endpoint and when the ID semantics are correct (ID != 0 and used externally). The patch also ensures an ID is marked available only when appropriate. The change is intentionally narrow and surgical — it fixes bookkeeping rather than refactoring logic — which reduces the risk of regressions in unrelated MPTCP behaviors.
Canonical steps taken by the kernel team:
If you operate Linux hosts that enable or might use MPTCP, treat this as an operational priority: inventory, patch, reboot where necessary, and harden the local attack surface. Watch kernel logs for the telltale WARN_ON_ONCE messages near the MPTCP path‑manager and validate that your distribution's kernel builds include the upstream fixes. The change is small in code but significant in operational consequence — and it is a useful reminder that kernel correctness in networking code is critical to platform availability.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background
Multipath TCP (MPTCP) is a kernel‑level extension to TCP that lets a single logical connection use multiple network interfaces or paths simultaneously. That capability is increasingly used in mobile devices, link‑aggregation scenarios, and cloud‑native networking stacks where path diversity improves throughput and resilience. Because MPTCP touches low‑level socket and path management logic, kernel bugs in MPTCP have immediate consequences for connection stability and host availability.In September 2024 maintainers merged a small but important patch to the MPTCP path‑manager that addresses incorrect bookkeeping when endpoints are removed. The problem showed up during the "remove single address" and related MPTCP selftests: the code could mark the wrong type of endpoint as having freed an address ID and then decrement an internal counter that tracks how many local addresses are in use. That mismatch could drive the counter negative or otherwise desynchronize accounting, producing WARN_ON_ONCE messages and enabling crash or availability conditions in the MPTCP management path.
What exactly went wrong? Technical overview
At the heart of CVE‑2024‑45010 is a logic error in how the path manager (PM) distinguishes endpoint types when handling netlink "remove address/subflow" operations.- The MPTCP PM distinguishes between endpoint types: subflow endpoints (addresses created to form subflows), signal endpoints (addresses used for signaling), and other implicit/derived endpoint kinds.
- The kernel maintains a per‑socket counter local_addr_used that is meant to reflect usage of subflow endpoints (addresses that are actually used to create subflows).
- When a netlink request removes a signal endpoint, the existing code path could walk linked subflows and call the subflow removal helper mptcp_pm_nl_rm_addr_or_subflow() with rm_type == MPTCP_MIB_RMSUBFLOW. In that process the code could incorrectly decrement local_addr_used even though the removed endpoint was a signal endpoint — not a subflow. That decrement is incorrect because the counter is not intended to track signal endpoints.
Why this matters: incorrect accounting in a kernel networking stack can cascade. If an ID is marked available when it is in use, later operations may allocate or free resources improperly; if counters are decremented incorrectly, re‑addition of addresses can be misrouted or refused, and in the worst case use‑after‑free or assertion paths may trigger panics, oopses, or a kernel crash — all resulting in loss of availability for networking services. Multiple vendors flagged the impact as an availability risk.
Affected kernels and severity
Independent tracking sources and vendor advisories show the same core facts:- The flaw was discovered during testing and disclosed publicly around 2024‑09‑11.
- The CVSSv3 base score assigned is 5.5 (Medium) with the vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H — local attack vector with high impact on availability but no confidentiality or integrity impacts listed.
Note: the vulnerability requires local privileges (low privilege required), so remote attackers cannot exploit this over the network unless they already have a local ability to submit the specific MPTCP operations (for example, via a local process or a compromised container). That said, the availability impact is real: an attacker who can exercise the MPTCP netlink interfaces or cause the kernel to process the offending path‑manager sequences can cause sustained or persistent denial‑of‑service on MPTCP‑using hosts.
How the bug was found: selftests and syzbot
The issue was surfaced by the Linux kernel's own MPTCP selftests (mptcp_join.sh) and automated testing (syzbot). The patches and commit log explicitly reference a failing "remove single address" subtest and warnings produced while running syzbot workloads. This is a common and positive pattern: test harnesses and continuous fuzzing catch logic races and accounting errors that are otherwise hard to trigger in production.Developers added a defensive check (WARN_ON_ONCE) to expose the pathological condition during testing, then updated the code so the local_addr_used counter is only decremented when the removal is operating on a true subflow endpoint and when the ID semantics are correct (ID != 0 and used externally). The patch also ensures an ID is marked available only when appropriate. The change is intentionally narrow and surgical — it fixes bookkeeping rather than refactoring logic — which reduces the risk of regressions in unrelated MPTCP behaviors.
Practical impact for administrators and operators
What this vulnerability means for real systems depends on whether the host actually uses MPTCP and how network namespaces, containers, and privileges are configured:- Hosts that do not enable or use MPTCP are not affected in practice.
- Systems that enable MPTCP (mobile devices, network appliances, some containerized workloads) are in scope. In cloud environments where multitenant workloads or customer containers might be able to trigger MPTCP netlink actions, the risk is higher.
- The exploitation scenario is local: an attacker needs the ability to execute actions that cause the MPTCP PM to remove endpoints or subflows. This could be achieved by a local unprivileged process if the environment offers access to MPTCP sockets, or by a malicious container/VM that can exercise the relevant kernel interfaces.
Vendor and upstream remediation
Upstream kernel maintainers accepted a small set of commits that correct the marking and counter‑decrement logic in the MPTCP PM code. The fix was pushed to the stable trees and backported to appropriate kernel stable branches. Multiple distribution vendors (SUSE, Oracle Linux, AWS ALAS and others) incorporated the kernel fix into vendor updates and announced security advisories that reference CVE‑2024‑45010 along with related MPTCP fixes.Canonical steps taken by the kernel team:
- Add defensive warnings to expose counter underflow conditions.
- Restrict marking an ID as "available" and decrementing local_addr_used to the precise subflow removal paths, only when ID semantics are valid and ID != 0.
- Ensure the re‑use/re‑mark logic is coherent: if no subflow is attached to a subflow endpoint, mark its ID available and decrement only when appropriate.
Detection and short‑term mitigations
If you cannot immediately patch, take the following steps to reduce exposure and detect attempted triggers:- Check kernel logs (dmesg, journalctl) for MPTCP PM warnings referencing local_addr_used or the specific warning string inserted by developers. A WARN_ON_ONCE with local_addr_used is a strong indicator the issue was triggered.
- Identify hosts that actually use MPTCP: search for MPTCP kernel module presence, check /proc/net or socket listings, and audit applications and containers for explicit MPTCP usage. If MPTCP is not used, consider disabling it in kernel build/boot configs or via sysctl if your distribution exposes a toggle.
- Restrict unprivileged access to network namespace and netlink interfaces: limit which containers and users can create and manipulate MPTCP sockets and netlink messages. Use container isolation and mandatory access controls to reduce the chance of a low‑privilege actor exercising the vulnerable code paths.
- Watch for increased kernel WARN/OOPS messages on networking hosts and treat them as high priority for investigation and patching.
Recommended remediation path (step‑by‑step)
- Inventory: find all hosts that run kernels in the affected range and that have MPTCP enabled. Confirm kernel versions against vendor advisories.
- Prioritize: schedule upgrades for production routers, multi‑tenant hosts, and edge devices that use MPTCP. Treat network hosts with public exposure or heavy container density as high priority.
- Patch: apply vendor kernel updates or upstream stable kernel releases that include the CVE‑2024‑45010 fix. Reboot hosts as required by distribution guidance.
- Verify: after patching, watch kernel logs for the previously observed WARN_ON_ONCE messages. Run relevant MPTCP selftests if feasible to validate behavior.
- Harden: limit local netlink/socket access to trusted users and containers; enforce container isolation and capabilities restrictions for untrusted workloads.
Why this is not just a "small patch" — operational implications
On the surface CVE‑2024‑45010 is a bookkeeping fix: "only decrement the counter for subflow endpoints." But bookkeeping errors in kernel networking can have outsized operational effects:- Kernel networking stacks are highly stateful. A wrong counter or ID marking can desynchronize allocation semantics across time, enabling either immediate crashes or subtle resource exhaustion scenarios that only manifest after multiple operations.
- MPTCP is often used to improve resilience; a bug that destabilizes MPTCP logic may reduce resilience and availability — the exact opposite of the purpose for which MPTCP was deployed.
- Cloud and edge platforms that allow local tenants or containers to create sockets increase the attack surface: a local, low‑privilege process can trigger conditions that affect the host and, by extension, other tenants. This is why availability‑impacting local vulnerabilities are treated seriously despite their local attack vector designation.
Relation to other MPTCP fixes (context)
CVE‑2024‑45010 appeared alongside several related MPTCP fixes in the same timeframe (for example CVE‑2024‑45009 and CVE‑2024‑50085), all addressing subtle counter, flag, or use‑after‑free issues in the MPTCP PM or netlink interfaces. That clustering is not accidental: fuzzing and selftests often reveal multiple, related correctness gaps in the same subsystem. Operators should treat the entire set as a coordinated maintenance window for MPTCP code rather than a one‑off patch.Risk assessment: how worried should you be?
- Severity: Medium (CVSS 5.5) but with High availability impact in practice for affected hosts. The limitation to local attack vector reduces global remote‑exposure risk, but does not eliminate serious consequences in multi‑tenant or containerized environments.
- Exploitability: No public exploit widely reported at the time of the fixes; the issue was discovered by internal testing and syzbot. However, the underlying operations required for exploitation are not complex once local access exists, so environments that allow local untrusted code execution into MPTCP APIs should patch quickly.
- Operational impact of patching: kernel updates and reboots are required; plan maintenance windows. The patch itself is small and surgery‑oriented, so the risk of regression is low relative to large refactors — but as always, verify in staging where possible.
For defenders: monitoring, post‑patch validation, and long‑term controls
- Monitoring: add kernel log alerts for WARN_ON_ONCE and MPTCP PM warnings; track OOPS and KASAN messages on networking hosts. Correlate with container lifecycle events and unprivileged process activity.
- Post‑patch validation: run the MPTCP selftests and any vendor regression tests; confirm that add/remove address operations behave without generating WARNs.
- Long‑term: consider minimizing in‑kernel exposure by decentralizing control-plane actions (when possible) and hardening local interfaces. For cloud providers and multi‑tenant hosts, enforce strict capability and namespace boundaries and sanitize which workloads can open raw netlink operations.
Conclusion
CVE‑2024‑45010 is a textbook case of how small accounting errors in kernel networking code can create outsized availability risks. The bug was responsibly discovered through selftests and automated fuzzing, and upstream maintainers merged surgical fixes that were backported by vendors. Despite its Medium CVSS rating, the practical effect can be severe for hosts that use MPTCP or that expose local netlink and socket interfaces to untrusted workloads.If you operate Linux hosts that enable or might use MPTCP, treat this as an operational priority: inventory, patch, reboot where necessary, and harden the local attack surface. Watch kernel logs for the telltale WARN_ON_ONCE messages near the MPTCP path‑manager and validate that your distribution's kernel builds include the upstream fixes. The change is small in code but significant in operational consequence — and it is a useful reminder that kernel correctness in networking code is critical to platform availability.
Source: MSRC Security Update Guide - Microsoft Security Response Center