CVE-2026-80585: mptcp: fastopen: only mark MPTFO subflows with SYN data
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.
mptcpfastopensubflowsynacksetparams() set ismptfo 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 checkfullyestablished().
Only mark the subflow as MPTFO after confirming that an SKB was queued. Return quietly when the receive queue is empty.
Note that mptcpsubflowcontext's ismptfo 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".
Event History
Frequently Asked Questions
Which connections are affected by this condition?
The condition requires a passive TCP Fast Open connection using a valid cookie where the SYN carries no data. It affects MPTCP subflows during SYN-ACK parameter setup.
What can happen if the warning does not terminate processing?
The subflow can retain stale MPTFO state after the receive queue is found empty. That stale flag can later cause state confusion in check_fully_established().
How does the resolved behavior distinguish affected subflows?
A subflow is marked as MPTFO only after queued SYN data is confirmed. A valid TCP Fast Open cookie without SYN data is no longer treated as an MPTFO subflow.