netdev - Re: [PATCH net 1/3] netfilter: nf_conntrack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 1 Sep 2022 08:46:34 -0400
From:   Neal Cardwell <ncardwell@...gle.com>
To:     Florian Westphal <fw@...len.de>
Cc:     Thomas Backlund <tmb@....nu>, Jakub Kicinski <kuba@...nel.org>,
        stable@...nel.org, patchwork-bot+netdevbpf@...nel.org,
        Pablo Neira Ayuso <pablo@...filter.org>, davem@...emloft.net,
        netdev@...r.kernel.org, Yuchung Cheng <ycheng@...gle.com>,
        Eric Dumazet <edumazet@...gle.com>,
        netfilter-devel@...r.kernel.org
Subject: Re: [PATCH net 1/3] netfilter: nf_conntrack_tcp: re-init for syn
 packets only

 theOn Fri, Aug 12, 2022 at 9:27 PM Thomas Backlund <tmb@....nu> wrote:
>
> Den 2022-08-12 kl. 22:17, skrev Jakub Kicinski:
> > On Fri, 12 Aug 2022 09:34:14 -0400 Neal Cardwell wrote:
> >> This first commit is an important bug fix for a serious bug that causes
> >> TCP connection hangs for users of TCP fast open and nf_conntrack:
> >>
> >>    c7aab4f17021b netfilter: nf_conntrack_tcp: re-init for syn packets only
> >>
> >> We are continuing to get reports about the bug that this commit fixes.
> >>
> >> It seems this fix was only backported to v5.17 stable release, and not further,
> >> due to a cherry-pick conflict, because this fix implicitly depends on a
> >> slightly earlier v5.17 fix in the same spot:
> >>
> >>    82b72cb94666 netfilter: conntrack: re-init state for retransmitted syn-ack
> >>
> >> I manually verified that the fix c7aab4f17021b can be cleanly cherry-picked
> >> into the oldest (v4.9.325) and newest (v5.15.60) longterm release kernels as
> >> long as we first cherry-pick that related fix that it implicitly depends on:
> >>
> >> 82b72cb94666b3dbd7152bb9f441b068af7a921b
> >> netfilter: conntrack: re-init state for retransmitted syn-ack
> >>
> >> c7aab4f17021b636a0ee75bcf28e06fb7c94ab48
> >> netfilter: nf_conntrack_tcp: re-init for syn packets only
> >>
> >> So would it be possible to backport both of those fixes with the following
> >> cherry-picks, to all LTS stable releases?
> >>
> >> git cherry-pick 82b72cb94666b3dbd7152bb9f441b068af7a921b
> >> git cherry-pick c7aab4f17021b636a0ee75bcf28e06fb7c94ab48
> >
> > Thanks a lot Neal! FWIW we have recently changed our process and no
> > longer handle stable submissions ourselves, so in the future feel free
> > to talk directly to stable@ (and add CC: stable@ tags to patches).
> >
> > I'm adding stable@, let's see if Greg & team can pick things up based
> > on your instructions :)
> >
>
> besides testing that they apply,
> one should also check that the resulting code actually builds...
>
> net/netfilter/nf_conntrack_proto_tcp.c: In function 'tcp_in_window':
> net/netfilter/nf_conntrack_proto_tcp.c:560:3: error: implicit
> declaration of function 'tcp_init_sender'; did you mean 'tcp_init_cwnd'?
> [-Werror=implicit-function-declaration]
>
>
>
> So this one is also needed:
> cc4f9d62037ebcb811f4908bba2986c01df1bd50
> netfilter: conntrack: move synack init code to helper
>
> for it to actually build on 5.15

Thomas – thanks for catching that!

Florian, can you please confirm that the following patch series would
be a correct and sensible set of cherry-picks to backport to stable to
fix this critical nf_conntrack_tcp bug that is black-holing TCP Fast
Open connections?

# netfilter: conntrack: move synack init code to helper
git cherry-pick cc4f9d62037ebcb811f4908bba2986c01df1bd50

# netfilter: conntrack: re-init state for retransmitted syn-ack
git cherry-pick 82b72cb94666b3dbd7152bb9f441b068af7a921b

# netfilter: nf_conntrack_tcp: re-init for syn packets only
git cherry-pick c7aab4f17021b636a0ee75bcf28e06fb7c94ab48

(When applied to v4.9.325 the first one needs a trivial conflict
resolution, but the second two apply cleanly. And the kernel
compiles.)

thanks,
neal