<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 29 Sep 2026 11:35:37 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-80585 — mptcp: fastopen: only mark MPTFO subflows with SYN data</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-80585</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mptcp: fastopen: only mark MPTFO subflows with SYN data&lt;/p&gt;
&lt;p&gt;Passive TCP Fast Open accepts a valid-cookie SYN even when it carries
no data. In that case the child socket&amp;#39;s receive queue is intentionally
left empty.&lt;/p&gt;
&lt;p&gt;mptcp_fastopen_subflow_synack_set_params() set is_mptfo 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
check_fully_established().&lt;/p&gt;
&lt;p&gt;Only mark the subflow as MPTFO after confirming that an SKB was queued.
Return quietly when the receive queue is empty.&lt;/p&gt;
&lt;p&gt;Note that mptcp_subflow_context&amp;#39;s is_mptfo 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 &amp;#34;doing TFO&amp;#34;.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mptcp: fastopen: only mark MPTFO subflows with SYN data&lt;/p&gt;
&lt;p&gt;Passive TCP Fast Open accepts a valid-cookie SYN even when it carries
no data. In that case the child socket&amp;#39;s receive queue is intentionally
left empty.&lt;/p&gt;
&lt;p&gt;mptcp_fastopen_subflow_synack_set_params() set is_mptfo 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
check_fully_established().&lt;/p&gt;
&lt;p&gt;Only mark the subflow as MPTFO after confirming that an SKB was queued.
Return quietly when the receive queue is empty.&lt;/p&gt;
&lt;p&gt;Note that mptcp_subflow_context&amp;#39;s is_mptfo 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 &amp;#34;doing TFO&amp;#34;.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-80585</guid>
    </item>
  </channel>
</rss>
