CVE-2026-80585 in Linux
Summary
by MITRE • 08/26/2026
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fastopen: only mark MPTFO subflows with SYN data
Passive TCP Fast Open accepts a valid-cookie SYN even when it carries no data. In that case the child socket's receive queue is intentionally left empty.
mptcp_fastopen_subflow_synack_set_params() set is_mptfo before checking for queued SYN data. That made data-less TFO SYNs hit a WARN and, if the warning was non-fatal, left stale MPTFO state behind. The stale flag could later trigger a state-confusion bug in check_fully_established().
Only mark the subflow as MPTFO after confirming that an SKB was queued. Return quietly when the receive queue is empty.
Note that mptcp_subflow_context's is_mptfo field is now not just about subflows where the TFO was present, but about MPTFO subflow that consumed SYN data. Only having a valid cookie but not carrying data is not really "doing TFO".
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The Linux kernel’s implementation of Multipath TCP Fast Open contains a logic error in the handling of passive connection establishment sequences that can lead to state confusion and potential denial of service conditions. Specifically, the vulnerability resides within the mptcp_fastopen_subflow_synack_set_params function, which is responsible for configuring parameters when processing incoming SYN packets during the initial handshake phase. The core issue stems from an incorrect ordering of operations where the kernel marks a subflow as utilizing Multipath TCP Fast Open by setting the is_mptfo flag before verifying whether the packet actually contains payload data. This deviation from the intended protocol behavior allows valid-cookie SYN packets that carry no application data to incorrectly trigger MPTFO state initialization, contrary to the design principle that TFO should only be considered active when data is transmitted alongside the initial connection request.
This premature marking of subflows results in two distinct negative outcomes depending on kernel configuration and warning levels. First, it triggers a WARN condition within the kernel logging subsystem because the code expects queued SYN data but finds an empty receive queue. While this immediate alert may not cause a crash if warnings are treated as non-fatal informational messages, it leaves behind stale MPTFO state information in memory. This residual state persists even though no actual Fast Open operation occurred, creating a discrepancy between the kernel’s internal representation of the connection and its true operational status. The presence of this incorrect flag sets the stage for more severe issues during subsequent connection management phases.
The most significant impact arises later when the check_fully_established function evaluates the state of the subflow to determine if the connection is ready for data transfer. Because the is_mptfo flag was incorrectly set earlier, this function may misinterpret the status of a standard TCP handshake as an MPTFO session. This state confusion can lead to improper handling of subsequent packets, potentially causing logic errors in how resources are allocated or released. In worst-case scenarios, such inconsistencies could be exploited by malicious actors to cause kernel panics through denial of service attacks, particularly if they craft specific sequences of SYN packets designed to exploit this race condition and state mismatch. The vulnerability effectively allows an attacker to manipulate the internal state machine of the MPTCP subsystem without necessarily needing to inject arbitrary code or gain privilege escalation, focusing instead on destabilizing network stack operations.
From a classification perspective, this flaw aligns with CWE-362, which describes concurrent execution issues and race conditions leading to improper synchronization, although in this case it is more accurately characterized as CWE-841, Improper Enforcement of Behavioral Workflow, due to the incorrect sequence of state transitions. In terms of attack vectors, this relates to MITRE ATT&CK technique T1496, Resource Hijacking, where an attacker might attempt to exhaust system resources or cause service disruption by triggering kernel warnings and leaving stale states that consume memory and processing cycles during cleanup operations. The vulnerability highlights the complexity involved in maintaining state consistency across different protocol layers within the Linux networking stack, particularly when optimizing for performance through features like Fast Open.
To mitigate this risk, developers have implemented a fix that reorders the logic to ensure the is_mptfo flag is only set after confirming that an SKB (Socket Buffer) containing data has been successfully queued in the receive buffer. This change ensures that subflows are marked as MPTFO exclusively when they genuinely consume SYN data, adhering strictly to the definition of Fast Open operations where data transmission occurs simultaneously with connection establishment. Systems running affected versions of the Linux kernel should apply the relevant patch or update provided by their distribution vendor immediately. Administrators monitoring system logs may observe increased WARN messages related to mptcp_fastopen_subflow_synack_set_params, which serves as an indicator that this vulnerability is being triggered in production environments. Continued vigilance and timely application of security updates are essential to prevent potential exploitation of this state confusion bug by adversaries seeking to disrupt network services or destabilize kernel stability.