CVE-2024-46711

What it actually does

Incorrect handling of 'local_addr_used' and 'add_addr_accepted' counters in MPTCP when the ID0 initial subflow endpoint is removed and re-added, causing the counters to be improperly incremented and preventing further re-creations of the endpoint.

Why it matters to the business

Causes multipath TCP connections to fail or lose redundancy after a single dynamic address change cycle, impacting high-availability networking, load balancing, and failover in Linux-based systems with frequent interface or route updates.

How an attack unfolds

An attacker triggers repeated removal and re-addition of the ID0 endpoint on an MPTCP connection, exhausting the address counters and locking the initial subflow, which disrupts ongoing sessions without requiring code execution.

How to fix it

Apply the upstream kernel fix from commit c9c744666f7308a4daba520191e29d395260bcfe; update to a stable release containing this commit for all affected kernel versions.

How to confirm the fix worked

Confirm presence of the fix by checking kernel git history for the referenced commit or by inspecting mptcp_pm.c for the corrected counter logic around ID0 endpoints.

Typical attack path

1. Establish or observe an MPTCP connection using ID0 endpoint
2. Trigger removal of the initial subflow endpoint
3. Re-add the same endpoint during the connection lifetime
4. Repeat the remove/re-add cycle to reach the counter limit

How to detect it

Examine kernel logs for MPTCP endpoint errors or warnings during address add/remove operations; monitor for unexpected drops in multipath subflows.

What your security team should do

• Prioritize kernel updates on systems using MPTCP
• Test MPTCP address management behavior after patching
• Review network configurations that rely on dynamic endpoint changes