CVE-2026-80587

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: avoid combining some incoming suboptions<br /> <br /> Some MPTCP suboptions are mutually exclusive according to the RFC8684,<br /> but also because in different places, the code doesn&amp;#39;t expect some<br /> combinations to be present. That&amp;#39;s specially true for suboptions that<br /> would be present twice, but with different attributes.<br /> <br /> The new restrictions are the same as the ones applied on the output<br /> side, with mptcp_write_options. The same rules can be reused with a<br /> small fix: an MP_FASTCLOSE can be used with a DSS when the sender picks<br /> this option [1], which is not the case on Linux. Here are the rules:<br /> <br /> Which options can be used together?<br /> <br /> X: mutually exclusive<br /> O: often used together<br /> C: can be used together in some cases<br /> P: could be used together but we prefer not to (optimisations)<br /> <br /> | Opt: | MPC | MPJ | DSS | ADD | RM | PRIO | FAIL | FC |<br /> |------|------|------|------|------|------|------|------|------|<br /> | MPC |------|------|------|------|------|------|------|------|<br /> | MPJ | X |------|------|------|------|------|------|------|<br /> | DSS | X | X |------|------|------|------|------|------|<br /> | ADD | X | X | P |------|------|------|------|------|<br /> | RM | C | C | C | P |------|------|------|------|<br /> | PRIO | X | C | C | C | C |------|------|------|<br /> | FAIL | X | X | C | X | X | X |------|------|<br /> | FC | X | X | P | X | X | X | X |------|<br /> | RST | X | X | X | X | X | X | O | O |<br /> |------|------|------|------|------|------|------|------|------|<br /> <br /> The only difference is with the &amp;#39;P&amp;#39;: another stack could send and<br /> ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be<br /> allowed.<br /> <br /> A few points of attention:<br /> <br /> - In theory, an MP_CAPABLE could be used with a RM_ADDR, but there is<br /> no reason to add it with a SYN. Note that even with a 4th ACK, it<br /> doesn&amp;#39;t seem to be useful, except when IDs are known in advance via<br /> another channel. Better not to break that.<br /> <br /> - Now, combining both an MP_CAPABLE and an MP_JOIN will no longer<br /> result to a reject of the two options, but only the second suboption<br /> is ignored. That seems OK to do that for this unexpected error. At<br /> least now all inconsistent combinations are handled the same way.<br /> This could change later in next. This also means the explicit checks<br /> for having both MPC + MPJ in subflow.c will now be unreachable.<br /> That&amp;#39;s fine, they will be removed in a follow-up patch.<br /> <br /> - In case of conflicting combinations, the extra suboption(s) is/are<br /> ignored: having such combinations either means the remote peer is<br /> buggy, or is evil. The simplest action is then taken in this case:<br /> stop processing the current suboption.<br /> <br /> - In mp_opt-&gt;suboptions, there is also a bit reserved to the checksum,<br /> which can be used in an MP_CAPABLE and a DSS. Each time a DSS option<br /> can be used in parallel with another option, the checksum can be set,<br /> so the verification is combined into a new OPTIONS_MPTCP_DSS macro.<br /> <br /> - An MP_CAPABLE ACK can carry a Data-Level Length, and an optional<br /> Checksum: they are the same as the ones found in a DSS, because a DSS<br /> cannot be used in parallel to an MP_CAPABLE. Similarly, even if there<br /> is room, a DSS cannot be used with an MP_JOIN.