All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Xin Long <lucien.xin@gmail.com>
Cc: network dev <netdev@vger.kernel.org>,
	netfilter-devel@vger.kernel.org, linux-sctp@vger.kernel.org,
	davem@davemloft.net, kuba@kernel.org,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	Pablo Neira Ayuso <pablo@netfilter.org>,
	Florian Westphal <fw@strlen.de>, Phil Sutter <phil@nwl.cc>,
	Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
	Yi Chen <yiche.cy@gmail.com>
Subject: Re: [PATCH net v2 0/2] sctp: fix a vtag verification failure caused by stale INITs
Date: Tue, 28 Apr 2026 15:06:42 +0100	[thread overview]
Message-ID: <20260428140642.GT900403@horms.kernel.org> (raw)
In-Reply-To: <cover.1777214801.git.lucien.xin@gmail.com>

On Sun, Apr 26, 2026 at 10:46:39AM -0400, Xin Long wrote:
> Similar to Scenario B in commit 8e56b063c865 ( netfilter: handle the
> connecting collision properly in nf_conntrack_proto_sctp"):
> 
> Scenario B: INIT_ACK is delayed until the peer completes its own handshake
> 
>   192.168.1.2 > 192.168.1.1: sctp (1) [INIT] [init tag: 3922216408]
>     192.168.1.1 > 192.168.1.2: sctp (1) [INIT] [init tag: 144230885]
>     192.168.1.2 > 192.168.1.1: sctp (1) [INIT ACK] [init tag: 3922216408]
>     192.168.1.1 > 192.168.1.2: sctp (1) [COOKIE ECHO]
>     192.168.1.2 > 192.168.1.1: sctp (1) [COOKIE ACK]
>   192.168.1.1 > 192.168.1.2: sctp (1) [INIT ACK] [init tag: 3914796021] *
> 
> There is another case:
> 
> Scenario F: INIT is delayed until the peer completes its own handshake
> 
>   192.168.1.2 > 192.168.1.1: sctp (1) [INIT] [init tag: 3922216408]
>   (OVS upcall)
>     192.168.1.1 > 192.168.1.2: sctp (1) [INIT] [init tag: 144230885]
>     192.168.1.2 > 192.168.1.1: sctp (1) [INIT ACK] [init tag: 3922216408]
>     192.168.1.1 > 192.168.1.2: sctp (1) [COOKIE ECHO]
>     192.168.1.2 > 192.168.1.1: sctp (1) [COOKIE ACK]
>   192.168.1.2 > 192.168.1.1: sctp (1) [INIT] [init tag: 3922216408]
>   (delayed)
>   192.168.1.1 > 192.168.1.2: sctp (1) [INIT ACK] [init tag: 3914796021] *
> 
> In this case, the delayed INIT (e.g. due to OVS upcall) is recorded by
> conntrack, which prevents vtag verification from dropping the unexpected
> INIT-ACK in nf_conntrack_sctp_packet():
> 
>   vtag = ct->proto.sctp.vtag[!dir];
>   if (!ct->proto.sctp.init[!dir] && vtag && vtag != ih->init_tag)
>           goto out_unlock;
> 
> This happens because ct->proto.sctp.init[!dir] is set by the delayed INIT,
> even though it is stale.
> 
> Fix this in two parts:
> 
> - In netfilter: Do not record INITs whose init_tag matches the peer vtag,
>   as they carry no new handshake state in the 1st patch.
> 
> - In SCTP: Prevent endpoints from responding to such INITs with INIT-ACK,
>   ensuring correctness even when middleboxes lack the netfilter fix in
>   the 2nd patch.
> 
> A follow-up selftest for this scenario will be posted in a separate patch
> by Yi Chen.

Hi Xin,

FTR: There is an AI generated review of this patchset available on
sashiko.dev. I have looked over this and I do not believe the feedback
there should block progress of this patchset.

  parent reply	other threads:[~2026-04-28 14:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-26 14:46 [PATCH net v2 0/2] sctp: fix a vtag verification failure caused by stale INITs Xin Long
2026-04-26 14:46 ` [PATCH net v2 1/2] netfilter: skip recording stale or retransmitted INIT Xin Long
2026-04-26 14:46 ` [PATCH net v2 2/2] sctp: discard stale INIT after handshake completion Xin Long
2026-04-28 14:06 ` Simon Horman [this message]
2026-04-28 20:15   ` [PATCH net v2 0/2] sctp: fix a vtag verification failure caused by stale INITs Xin Long
2026-04-29  1:30 ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260428140642.GT900403@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fw@strlen.de \
    --cc=kuba@kernel.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=lucien.xin@gmail.com \
    --cc=marcelo.leitner@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pablo@netfilter.org \
    --cc=phil@nwl.cc \
    --cc=yiche.cy@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.