CVE-2025-71144 Overview
A vulnerability has been identified in the Linux kernel's Multipath TCP (MPTCP) implementation where the subflow context is not properly reset during disconnect operations. When the MPC (Multipath Capable) subflow is already in TCP_CLOSE status or has fallen back to standard TCP at mptcp_disconnect() time, the mptcp_do_fastclose() function skips setting the send_fastclose flag. This causes the subsequent __mptcp_close_ssk() call to fail in resetting the related subflow context, leading to an inconsistent state that triggers kernel warnings on subsequent connections.
Critical Impact
This vulnerability can cause kernel warnings and potentially unstable system behavior when MPTCP connections are reused after disconnect, affecting systems with MPTCP-enabled network applications.
Affected Products
- Linux kernel versions with MPTCP support (versions prior to patches)
- Systems running kernel versions before commits 1c7c3a9, 5c7c713, 86730ac, or f1a77df
- Network-intensive applications utilizing Multipath TCP
Discovery Timeline
- 2026-01-14 - CVE-2025-71144 published to NVD
- 2026-01-14 - Last updated in NVD database
Technical Details for CVE-2025-71144
Vulnerability Analysis
This vulnerability resides in the MPTCP subsystem of the Linux kernel, specifically in the disconnect handling logic within net/mptcp/subflow.c. The issue manifests when a connection using MPTCP enters a specific state where the MPC subflow reaches TCP_CLOSE status or falls back to regular TCP before the mptcp_disconnect() function is called.
Under normal operation, the mptcp_do_fastclose() function should set the send_fastclose flag, which signals __mptcp_close_ssk() to properly reset the subflow context. However, when the subflow is already closed or has fallen back, this flag is never set, leaving the subflow context in an inconsistent state.
The kernel stack trace from the warning shows the issue propagates through the TCP data path: tcp_data_ready → tcp_data_queue → tcp_rcv_state_process → tcp_v4_do_rcv, ultimately triggering a warning at subflow_data_ready in net/mptcp/subflow.c:1519.
Root Cause
The root cause is a missing state synchronization in the MPTCP fast close mechanism. When mptcp_disconnect() is invoked, it unconditionally clears the msk-level fallback status. However, mptcp_do_fastclose() conditionally skips setting the send_fastclose flag based on the subflow's current state. This creates a window where:
- The fallback status is cleared at the MPTCP socket level
- The request_mptcp flag remains in an inconsistent state
- The subflow context retains stale state from the previous connection
Any subsequent connection attempt inherits this corrupted state, with both request_mptcp flag and msk-level fallback status in conflicting states, triggering the warning in subflow_data_ready().
Attack Vector
The vulnerability can be triggered through normal network operations involving MPTCP-enabled connections. An attacker or faulty application could potentially trigger this condition by:
- Establishing an MPTCP connection
- Forcing the connection to fall back to TCP or reach TCP_CLOSE state
- Calling disconnect on the socket
- Attempting to reuse the socket for a new connection
This results in kernel warnings and could potentially be leveraged for denial of service against systems heavily utilizing MPTCP for network redundancy or performance. The attack does not require special privileges beyond the ability to create network sockets.
The fix introduces an explicit fastclosing flag that is set during the fast close operation and checked after mptcp_do_fastclose() completes, ensuring proper state cleanup regardless of the subflow's current state.
Detection Methods for CVE-2025-71144
Indicators of Compromise
- Kernel warning messages containing subflow_data_ready at net/mptcp/subflow.c:1519
- System log entries showing MPTCP-related warnings with CPU and PID information similar to the pattern: WARNING: CPU: XX PID: XXXX at net/mptcp/subflow.c:1519
- Unexpected MPTCP connection failures or socket errors in applications using Multipath TCP
Detection Strategies
- Monitor kernel logs (dmesg, /var/log/kern.log) for MPTCP-related warnings referencing subflow_data_ready
- Implement alerting on kernel warning patterns matching the net/mptcp/subflow.c:1519 location
- Use kernel tracing tools to monitor MPTCP socket state transitions for anomalies
Monitoring Recommendations
- Deploy centralized log aggregation to collect and analyze kernel warning messages across systems using MPTCP
- Establish baseline metrics for MPTCP connection patterns and alert on unusual disconnect/reconnect cycles
- Monitor system stability metrics on servers with heavy MPTCP workloads for unexpected warnings or performance degradation
How to Mitigate CVE-2025-71144
Immediate Actions Required
- Update the Linux kernel to a version containing the fix (commits 1c7c3a9, 5c7c713, 86730ac, or f1a77df)
- Review and prioritize patching for systems actively using MPTCP features
- Consider temporarily disabling MPTCP on affected systems if patching is not immediately possible
Patch Information
The vulnerability has been addressed through multiple kernel patch commits. The fix introduces an explicit fastclosing flag that is set at fast close time and properly checked after mptcp_do_fastclose() completes, ensuring the subflow context is always reset correctly regardless of the subflow's state at disconnect time.
Patch commits are available from the Linux kernel stable tree:
- Kernel Patch Commit 1c7c3a9
- Kernel Patch Commit 5c7c713
- Kernel Patch Commit 86730ac
- Kernel Patch Commit f1a77df
Workarounds
- Disable MPTCP functionality system-wide by setting net.mptcp.enabled=0 via sysctl
- Configure applications to use standard TCP instead of MPTCP until patching can be completed
- Implement application-level connection handling to avoid rapid disconnect/reconnect patterns on MPTCP sockets
# Disable MPTCP system-wide as a temporary workaround
sysctl -w net.mptcp.enabled=0
# Make the change persistent across reboots
echo "net.mptcp.enabled=0" >> /etc/sysctl.conf
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

