Description
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.
Published: 2026-08-26
Score: 9.8 Critical
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service
Action: Patch Update
AI Analysis

Impact

The vulnerability arises from the Linux kernel’s MultiPath TCP (MPTCP) stack accepting combinations of suboptions that are mutually exclusive according to RFC8684 or incompatible with kernel logic. Without proper validation, these conflicting suboptions could be processed, leading to inconsistent state or protocol confusion within the network stack. The applied fix restores strict checks so that any offending suboptions are ignored, preventing unreliable socket behavior and potential service interruption. The primary impact is therefore a disruption of network communication that could manifest as a denial of service for affected connections.

Affected Systems

All builds of the Linux kernel that include the legacy MPTCP stack and have not applied the recent patch are potentially affected. The CVE lists a generic Linux kernel CPE, and no specific vendor or version information is provided, meaning any distribution running the default MPTCP support before the fix may be vulnerable.

Risk and Exploitability

Exploitation would require an attacker to transmit specially crafted TCP segments containing conflicting MPTCP suboptions to the target host. This is a remote, network‑based attack vector. The CVSS score of 9.8 indicates critical severity, but the EPSS score of less than 1% shows low likelihood of exploitation in the wild, and the vulnerability has not been listed in the CISA KEV catalog. Successful misuse could degrade or interrupt network communication but no publicly known exploit exists at this time.

Generated by OpenCVE AI on August 28, 2026 at 17:38 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the latest kernel release that includes the CVE-2026-80587 fix.
  • If an immediate kernel upgrade is infeasible, rebuild or reconfigure the kernel to disable MPTCP support entirely.
  • Optionally, configure network filtering to discard TCP segments that contain multiple or duplicate MPTCP suboptions, mitigating exploitation while preserving normal traffic.

Generated by OpenCVE AI on August 28, 2026 at 17:38 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 28 Aug 2026 16:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-20

Thu, 27 Aug 2026 18:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-1288
References
Metrics threat_severity

None

threat_severity

Moderate


Thu, 27 Aug 2026 13:00:00 +0000


Thu, 27 Aug 2026 09:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-20

Thu, 27 Aug 2026 08:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-20

Thu, 27 Aug 2026 06:15:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 9.8, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}


Wed, 26 Aug 2026 17:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-20

Wed, 26 Aug 2026 14:45:00 +0000

Type Values Removed Values Added
Description 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.
Title mptcp: avoid combining some incoming suboptions
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-27T12:40:23.299Z

Reserved: 2026-08-26T14:34:25.769Z

Link: CVE-2026-80587

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-26T15:17:15.017

Modified: 2026-08-27T13:18:41.093

Link: CVE-2026-80587

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-08-26T00:00:00Z

Links: CVE-2026-80587 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-28T17:45:04Z

Weaknesses
  • CWE-1288

    Improper Validation of Consistency within Input