{"id":11983,"date":"2026-09-04T18:54:00","date_gmt":"2026-09-04T10:54:00","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-80587"},"modified":"2026-09-04T18:54:00","modified_gmt":"2026-09-04T10:54:00","slug":"cve-2026-80587","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-80587","title":{"rendered":"CVE-2026-80587 [CRITICAL] &#8211; In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: avoid combinin"},"content":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>mptcp: avoid combining some incoming suboptions<\/p>\n<p>Some MPTCP suboptions are mutually exclusive according to the RFC8684,<br \/>\nbut also because in different places, the code doesn&#8217;t expect some<br \/>\ncombinations to be present. That&#8217;s specially true for suboptions that<br \/>\nwould be present twice, but with different attributes.<\/p>\n<p>The new restrictions are the same as the ones applied on the output<br \/>\nside, with mptcp_write_options. The same rules can be reused with a<br \/>\nsmall fix: an MP_FASTCLOSE can be used with a DSS when the sender picks<br \/>\nthis option [1], which is not the case on Linux. Here are the rules:<\/p>\n<p>  Which options can be used together?<\/p>\n<p>  X: mutually exclusive<br \/>\n  O: often used together<br \/>\n  C: can be used together in some cases<br \/>\n  P: could be used together but we prefer not to (optimisations)<\/p>\n<p>  | Opt: | MPC  | MPJ  | DSS  | ADD  |  RM  | PRIO | FAIL |  FC  |<br \/>\n  |&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|<br \/>\n  | MPC  |&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|<br \/>\n  | MPJ  |  X   |&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|<br \/>\n  | DSS  |  X   |  X   |&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|<br \/>\n  | ADD  |  X   |  X   |  P   |&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|<br \/>\n  | RM   |  C   |  C   |  C   |  P   |&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|<br \/>\n  | PRIO |  X   |  C   |  C   |  C   |  C   |&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|<br \/>\n  | FAIL |  X   |  X   |  C   |  X   |  X   |  X   |&#8212;&#8212;|&#8212;&#8212;|<br \/>\n  | FC   |  X   |  X   |  P   |  X   |  X   |  X   |  X   |&#8212;&#8212;|<br \/>\n  | RST  |  X   |  X   |  X   |  X   |  X   |  X   |  O   |  O   |<br \/>\n  |&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|&#8212;&#8212;|<\/p>\n<p>The only difference is with the &#8216;P&#8217;: another stack could send and<br \/>\nADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be<br \/>\nallowed.<\/p>\n<p>A few points of attention:<\/p>\n<p> &#8211; In theory, an MP_CAPABLE could be used with a RM_ADDR, but there is<br \/>\n   no reason to add it with a SYN. Note that even with a 4th ACK, it<br \/>\n   doesn&#8217;t seem to be useful, except when IDs are known in advance via<br \/>\n   another channel. Better not to break that.<\/p>\n<p> &#8211; Now, combining both an MP_CAPABLE and an MP_JOIN will no longer<br \/>\n   result to a reject of the two options, but only the second suboption<br \/>\n   is ignored. That seems OK to do that for this unexpected error. At<br \/>\n   least now all inconsistent combinations are handled the same way.<br \/>\n   This could change later in next. This also means the explicit checks<br \/>\n   for having both MPC + MPJ in subflow.c will now be unreachable.<br \/>\n   That&#8217;s fine, they will be removed in a follow-up patch.<\/p>\n<p> &#8211; In case of conflicting combinations, the extra suboption(s) is\/are<br \/>\n   ignored: having such combinations either means the remote peer is<br \/>\n   buggy, or is evil. The simplest action is then taken in this case:<br \/>\n   stop processing the current suboption.<\/p>\n<p> &#8211; In mp_opt-&gt;suboptions, there is also a bit reserved to the checksum,<br \/>\n   which can be used in an MP_CAPABLE and a DSS. Each time a DSS option<br \/>\n   can be used in parallel with another option, the checksum can be set,<br \/>\n   so the verification is combined into a new OPTIONS_MPTCP_DSS macro.<\/p>\n<p> &#8211; An MP_CAPABLE ACK can carry a Data-Level Length, and an optional<br \/>\n   Checksum: they are the same as the ones found in a DSS, because a DSS<br \/>\n   cannot be used in parallel to an MP_CAPABLE. Similarly, even if there<br \/>\n   is room, a DSS cannot be used with an MP_JOIN.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>mptcp: avoid combining some incoming suboptions<\/p>\n<p>Some MPTCP suboptions are mutually exclusive according to the RFC8684,<br \/>\nbut also be<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-11983","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/11983","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=11983"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=11983"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=11983"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}