netdev - Re: Commit 09e856d54bda5f288ef8437a90ab2b9b3eab83d1r "vrf: Reset skb conntrack connection on VRF rcv" breaks expected netfilter behaviour

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]

Message-ID: <20211019144142.5308fc84@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Tue, 19 Oct 2021 14:41:42 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Florian Westphal <fw@...len.de>, David Ahern <dsahern@...nel.org>
Cc:     Eugene Crosser <crosser@...rage.org>, netdev@...r.kernel.org,
        netfilter-devel@...r.kernel.org,
        Lahav Schlesinger <lschlesinger@...venets.com>
Subject: Re: Commit 09e856d54bda5f288ef8437a90ab2b9b3eab83d1r "vrf: Reset
 skb conntrack connection on VRF rcv" breaks expected netfilter behaviour

On Fri, 15 Oct 2021 23:04:48 +0200 Florian Westphal wrote:
> Florian Westphal <fw@...len.de> wrote:
> > 'track' is hard to implement correctly because of RELATED traffic.
> > 
> > E.g. 'tcp dport 22 track' won't work correctly because icmp pmtu
> > won't be handled.
> > 
> > I'd suggest to try a conditional nf_ct_reset that keeps the conntrack
> > entry if its in another zone.
> > 
> > I can't think of another solution at the moment, the existing behaviour
> > of resetting conntrack entry for postrouting/output is too old,
> > otherwise the better solution IMO would be to keep that entry around on
> > egress if a NAT rewrite has been done. This would avoid the 'double snat'
> > problem that the 'reset on ingress' tries to solve.  
> 
> I'm working on this.
> 
> Eugene, I think it makes sense if you send a formal revert, a proper
> fix for snat+vrf needs more work.

If this is still the plan can we get some acks on the revert please?

https://patchwork.kernel.org/project/netdevbpf/patch/20211018182250.23093-2-crosser@average.org/