CVE-2026-80587 in Linux
Summary
by MITRE • 08/26/2026
In the Linux kernel, the following vulnerability has been resolved:
mptcp: avoid combining some incoming suboptions
Some MPTCP suboptions are mutually exclusive according to the RFC8684, but also because in different places, the code doesn't expect some combinations to be present. That's specially true for suboptions that would be present twice, but with different attributes.
The new restrictions are the same as the ones applied on the output side, with mptcp_write_options. The same rules can be reused with a small fix: an MP_FASTCLOSE can be used with a DSS when the sender picks this option [1], which is not the case on Linux. Here are the rules:
Which options can be used together?
X: mutually exclusive O: often used together C: can be used together in some cases P: could be used together but we prefer not to (optimisations)
| Opt: | MPC | MPJ | DSS | ADD | RM | PRIO | FAIL | FC | |------|------|------|------|------|------|------|------|------| | MPC |------|------|------|------|------|------|------|------| | MPJ | X |------|------|------|------|------|------|------| | DSS | X | X |------|------|------|------|------|------| | ADD | X | X | P |------|------|------|------|------| | RM | C | C | C | P |------|------|------|------| | PRIO | X | C | C | C | C |------|------|------| | FAIL | X | X | C | X | X | X |------|------| | FC | X | X | P | X | X | X | X |------| | RST | X | X | X | X | X | X | O | O | |------|------|------|------|------|------|------|------|------|
The only difference is with the 'P': another stack could send and ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be allowed.
A few points of attention:
- In theory, an MP_CAPABLE could be used with a RM_ADDR, but there is no reason to add it with a SYN. Note that even with a 4th ACK, it doesn't seem to be useful, except when IDs are known in advance via another channel. Better not to break that.
- Now, combining both an MP_CAPABLE and an MP_JOIN will no longer result to a reject of the two options, but only the second suboption is ignored. That seems OK to do that for this unexpected error. At least now all inconsistent combinations are handled the same way. This could change later in next. This also means the explicit checks for having both MPC + MPJ in subflow.c will now be unreachable. That's fine, they will be removed in a follow-up patch.
- In case of conflicting combinations, the extra suboption(s) is/are ignored: having such combinations either means the remote peer is buggy, or is evil. The simplest action is then taken in this case: stop processing the current suboption.
- In mp_opt->suboptions, there is also a bit reserved to the checksum, which can be used in an MP_CAPABLE and a DSS. Each time a DSS option can be used in parallel with another option, the checksum can be set, so the verification is combined into a new OPTIONS_MPTCP_DSS macro.
- An MP_CAPABLE ACK can carry a Data-Level Length, and an optional Checksum: they are the same as the ones found in a DSS, because a DSS cannot be used in parallel to an MP_CAPABLE. Similarly, even if there is room, a DSS cannot be used with an MP_JOIN.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/26/2026
The Linux kernel has addressed a critical implementation flaw within its Multipath TCP (MPTCP) subsystem that allows for the processing of mutually exclusive suboptions during connection establishment and data transfer phases. This vulnerability stems from insufficient validation logic when parsing incoming MPTCP options, specifically failing to enforce the mutual exclusivity constraints defined in RFC 8684. In a compliant implementation, certain MPTCP suboptions such as MP_CAPABLE, MP_JOIN, Data Sequence Signal (DSS), and others are designed to be mutually exclusive or have strict compatibility rules due to their distinct roles in connection setup versus data transmission. The previous code allowed combinations of these options that violate the protocol specification, potentially leading to undefined behavior, state machine confusion, or denial of service conditions where the kernel might misinterpret packet structures or fail to process subsequent valid packets correctly.
The core technical flaw involves the lack of rigorous checks on incoming suboptions before they are integrated into the connection's operational context. According to RFC 8684 and related specifications, options like MP_CAPABLE and MP_JOIN serve different phases of the MPTCP handshake; combining them in a manner that violates their defined interaction rules creates an inconsistent state within the kernel’s network stack. For instance, while some combinations are strictly prohibited due to protocol design, others might be technically permissible under specific edge cases but were previously handled inconsistently or not at all. The vulnerability arises because the input parsing logic did not mirror the output validation logic used by mptcp_write_options, creating an asymmetry that malicious actors could exploit. By sending crafted packets containing forbidden combinations of suboptions, an attacker can trigger this inconsistency, potentially causing the kernel to drop valid traffic, enter a broken state, or exhibit unpredictable behavior in multi-path routing decisions.
The resolution implements strict validation rules for incoming MPTCP options by reusing and adapting the logic already present in the output path. The updated code enforces that mutually exclusive suboptions are not processed together, ensuring compliance with RFC 8684 requirements. Specifically, if a packet contains conflicting combinations such as MP_CAPABLE alongside MP_JOIN or DSS where prohibited, the kernel now ignores the invalid suboption rather than attempting to process it. This approach prevents state corruption and maintains protocol integrity. The fix also clarifies edge cases, such as allowing an MP_FASTCLOSE option when paired with a Data Sequence Signal under specific sender-selected conditions, while maintaining strict prohibitions on other incompatible pairs like FAIL combined with most other options or RST combined with non-RST options except in defined contexts. This uniform handling ensures that inconsistent combinations are treated consistently across the stack, reducing the attack surface for protocol-level exploits.
From a security perspective, this vulnerability aligns with CWE-20 Improper Input Validation and potentially CWE-841 Improper Enforcement of Behavioral Rules, as the system failed to enforce defined behavioral constraints on incoming data structures. In terms of MITRE ATT&CK mapping, this relates to Tactic TA0001 Initial Access or TA0005 Defense Evasion if exploited for stealthy disruption, and specifically Technique T1498 Network Denial of Service via protocol confusion or resource exhaustion due to malformed state handling. The ability to send conflicting suboptions could be leveraged in denial-of-service attacks against MPTCP-enabled services by forcing the kernel into error states that require restarts or cause packet drops for legitimate traffic. Furthermore, improper parsing of network protocols can sometimes lead to memory corruption if subsequent processing assumes valid structures based on malformed headers, although this specific fix focuses primarily on logical consistency and state management rather than buffer overflows.
Mitigation strategies involve applying the latest kernel patches that include these validation checks. Administrators should ensure their systems are updated with versions of the Linux kernel where mptcp_write_options logic is correctly mirrored in input parsing routines. For environments heavily reliant on MPTCP, monitoring for unusual connection states or dropped packets during high-volume traffic may help detect exploitation attempts. Additionally, network segmentation and firewall rules that restrict direct exposure of MPTCP ports to untrusted networks can reduce the risk profile until all endpoints are patched. It is crucial to recognize that while this fix addresses immediate logical inconsistencies, ongoing vigilance regarding protocol compliance in kernel networking stacks remains essential for maintaining robust defense-in-depth against sophisticated attackers targeting transport layer implementations.