From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Cc: netfilter-devel@vger.kernel.org, Florian Westphal <fw@strlen.de>,
Phil Sutter <phil@nwl.cc>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
coreteam@netfilter.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>,
Ao Wang <wangao@seu.edu.cn>, Xuewei Feng <fengxw06@126.com>,
Qi Li <qli01@tsinghua.edu.cn>, Ke Xu <xuke@tsinghua.edu.cn>
Subject: Re: [PATCH nf] netfilter: conntrack: sctp: verify vtag before state changes
Date: Fri, 31 Jul 2026 12:33:20 +0200 [thread overview]
Message-ID: <amx58O5Jb6B29XDJ@chamomile> (raw)
In-Reply-To: <AD2FFF7F-7EC3-4205-BB44-508B31BC2620@mails.tsinghua.edu.cn>
On Wed, Jul 29, 2026 at 12:56:39PM +0800, Yizhou Zhao wrote:
> Hi Pablo,
>
> Thank you for the review.
>
> > On Jul 29, 2026, at 03:26, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> >
> > Hi,
> >
> > On Tue, Jul 28, 2026 at 03:35:06PM +0800, Yizhou Zhao wrote:
> >> The packet-wide vtag check in nf_conntrack_sctp_packet() is skipped when
> >> the bundle map contains any chunk type with special vtag handling. The
> >> per-chunk path re-checks INIT, ABORT, SHUTDOWN_COMPLETE, and
> >> COOKIE_ECHO, but other state-changing chunks still fall through to
> >> sctp_new_state() without validating sh->vtag.
> >>
> >> This lets a wrong-vtag packet bundle HEARTBEAT with COOKIE_ACK, ERROR,
> >> SHUTDOWN, or SHUTDOWN_ACK and still advance conntrack state. That can
> >> desynchronize conntrack from the real SCTP association and cause denial
> >> of service for SCTP traffic behind a stateful firewall.
> >
> > Are you assuming a specific policy in place? The connection tracking
> > does not police packets, it just provides tracking.
>
> You are right, I overstated the impact. Conntrack only tracks packet
> state, and whether a packet is dropped depends on a firewall rule that
> uses that state.
>
> >
> > Can you provide a more specific scenario?
>
> The issue I reproduced is that a wrong-vtag [SHUTDOWN, HEARTBEAT] bundle
> changes SCTP conntrack state from ESTABLISHED to SHUTDOWN_SENT, while the
> SCTP endpoints discard the packet because of the invalid vtag. This can
> therefore desynchronize conntrack from the association.
>
> For example, a stateful policy that drops INVALID, accepts
> ESTABLISHED/RELATED, and accepts new SCTP only for INIT will see the
> conntrack timeout change from 210 seconds to 3 seconds. If the entry
> expires while the real association remains established, a later DATA
> packet is invalid and that policy drops it. This requires an attacker
> that can inject a matching SCTP 4-tuple into the firewall path, and it does
> not require knowing the correct vtag.
>
> >
> > We are seeing several reports related to the connection tracking from
> > your university lately.
> >
> >> Check sh->vtag before processing those chunks when conntrack already
> >> knows the expected direction vtag. This keeps the existing
> >> HEARTBEAT/HEARTBEAT_ACK learning and connection-reuse behavior for the
> >> `vtag == 0` cases.
> >
> > Proposed patches to hardening the connection tracking state machine
> > should be targeted at nf-next.
>
> I agree this is better treated as SCTP conntrack state-machine hardening.
> If you agree, I will respin the patch for nf-next without Fixes or stable Cc.
Yes, repurpose this patch to nf-next without Fixes tag and stable for review.
Thanks.
next prev parent reply other threads:[~2026-07-31 10:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 7:35 [PATCH nf] netfilter: conntrack: sctp: verify vtag before state changes Yizhou Zhao
2026-07-28 19:26 ` Pablo Neira Ayuso
2026-07-29 4:56 ` Yizhou Zhao
2026-07-31 10:33 ` Pablo Neira Ayuso [this message]
2026-07-31 14:58 ` Yizhou Zhao
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=amx58O5Jb6B29XDJ@chamomile \
--to=pablo@netfilter.org \
--cc=coreteam@netfilter.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fengxw06@126.com \
--cc=fw@strlen.de \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=phil@nwl.cc \
--cc=qli01@tsinghua.edu.cn \
--cc=stable@vger.kernel.org \
--cc=wangao@seu.edu.cn \
--cc=xuke@tsinghua.edu.cn \
--cc=yangyx22@mails.tsinghua.edu.cn \
--cc=zhaoyz24@mails.tsinghua.edu.cn \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox