<?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>Thu, 01 Oct 2026 06:49:04 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-68227 — mptcp: Fix proto fallback detection with BPF</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-68227</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: Fix proto fallback detection with BPF&lt;/p&gt;
&lt;p&gt;The sockmap feature allows bpf syscall from userspace, or based
on bpf sockops, replacing the sk_prot of sockets during protocol stack
processing with sockmap&amp;#39;s custom read/write interfaces.
&amp;#39;&amp;#39;&amp;#39;
tcp_rcv_state_process()
  syn_recv_sock()/subflow_syn_recv_sock()
    tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB)
      bpf_skops_established       &amp;lt;== sockops
        bpf_sock_map_update(sk)   &amp;lt;== call bpf helper
          tcp_bpf_update_proto()  &amp;lt;== update sk_prot
&amp;#39;&amp;#39;&amp;#39;&lt;/p&gt;
&lt;p&gt;When the server has MPTCP enabled but the client sends a TCP SYN
without MPTCP, subflow_syn_recv_sock() performs a fallback on the
subflow, replacing the subflow sk&amp;#39;s sk_prot with the native sk_prot.
&amp;#39;&amp;#39;&amp;#39;
subflow_syn_recv_sock()
  subflow_ulp_fallback()
    subflow_drop_ctx()
      mptcp_subflow_ops_undo_override()
&amp;#39;&amp;#39;&amp;#39;&lt;/p&gt;
&lt;p&gt;Then, this subflow can be normally used by sockmap, which replaces the
native sk_prot with sockmap&amp;#39;s custom sk_prot. The issue occurs when the
user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops().
Here, it uses sk-&amp;gt;sk_prot to compare with the native sk_prot, but this
is incorrect when sockmap is used, as we may incorrectly set
sk-&amp;gt;sk_socket-&amp;gt;ops.&lt;/p&gt;
&lt;p&gt;This fix uses the more generic sk_family for the comparison instead.&lt;/p&gt;
&lt;p&gt;Additionally, this also prevents a WARNING from occurring:&lt;/p&gt;
&lt;p&gt;result from ./scripts/decode_stacktrace.sh:
------------[ cut here ]------------
WARNING:…&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: Fix proto fallback detection with BPF&lt;/p&gt;
&lt;p&gt;The sockmap feature allows bpf syscall from userspace, or based
on bpf sockops, replacing the sk_prot of sockets during protocol stack
processing with sockmap&amp;#39;s custom read/write interfaces.
&amp;#39;&amp;#39;&amp;#39;
tcp_rcv_state_process()
  syn_recv_sock()/subflow_syn_recv_sock()
    tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB)
      bpf_skops_established       &amp;lt;== sockops
        bpf_sock_map_update(sk)   &amp;lt;== call bpf helper
          tcp_bpf_update_proto()  &amp;lt;== update sk_prot
&amp;#39;&amp;#39;&amp;#39;&lt;/p&gt;
&lt;p&gt;When the server has MPTCP enabled but the client sends a TCP SYN
without MPTCP, subflow_syn_recv_sock() performs a fallback on the
subflow, replacing the subflow sk&amp;#39;s sk_prot with the native sk_prot.
&amp;#39;&amp;#39;&amp;#39;
subflow_syn_recv_sock()
  subflow_ulp_fallback()
    subflow_drop_ctx()
      mptcp_subflow_ops_undo_override()
&amp;#39;&amp;#39;&amp;#39;&lt;/p&gt;
&lt;p&gt;Then, this subflow can be normally used by sockmap, which replaces the
native sk_prot with sockmap&amp;#39;s custom sk_prot. The issue occurs when the
user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops().
Here, it uses sk-&amp;gt;sk_prot to compare with the native sk_prot, but this
is incorrect when sockmap is used, as we may incorrectly set
sk-&amp;gt;sk_socket-&amp;gt;ops.&lt;/p&gt;
&lt;p&gt;This fix uses the more generic sk_family for the comparison instead.&lt;/p&gt;
&lt;p&gt;Additionally, this also prevents a WARNING from occurring:&lt;/p&gt;
&lt;p&gt;result from ./scripts/decode_stacktrace.sh:
------------[ cut here ]------------
WARNING:…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2025-68227</guid>
    </item>
  </channel>
</rss>
