netdev - Re: [PATCH net] netfilter: nf_nat: fix action not being set for all ct states

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADvbK_dpD+rTPr4acbvmHu91OHtgynzJ4Ru3+d+rw7njmOPeww@mail.gmail.com>
Date: Thu, 28 Dec 2023 10:59:21 -0500
From: Xin Long <lucien.xin@...il.com>
To: Brad Cowie <brad@...cet.nz>
Cc: horms@...nel.org, aconole@...hat.com, coreteam@...filter.org, 
	davem@...emloft.net, dev@...nvswitch.org, edumazet@...gle.com, fw@...len.de, 
	kadlec@...filter.org, kuba@...nel.org, linux-kernel@...r.kernel.org, 
	netdev@...r.kernel.org, netfilter-devel@...r.kernel.org, pabeni@...hat.com, 
	pablo@...filter.org
Subject: Re: [PATCH net] netfilter: nf_nat: fix action not being set for all
 ct states

On Sat, Dec 23, 2023 at 9:48 PM Brad Cowie <brad@...cet.nz> wrote:
>
> On Sun, 24 Dec 2023 at 10:13, Simon Horman <horms@...nel.org> wrote:
> > Thanks Brad,
> >
> > I agree with your analysis and that the problem appears to
> > have been introduced by the cited commit.
>
> Thanks for the review Simon.
>
> > I am curious to know what use case triggers this /
> > why it when unnoticed for a year.
>
> We encountered this issue while upgrading some routers from
> linux 5.15 to 6.2. The dataplane on these routers is provided
> by an openvswitch bridge which is controlled via openflow by
> faucet. These routers are also performing SNAT on all traffic
> to/from the wan interface via openvswitch conntrack openflow
> rules.
>
> We noticed that after upgrading the linux kernel, traceroute/mtr
> no longer worked when run from clients behind the router.
> We eventually discovered the reason for this is that the
> ICMP time exceeded messages elicited by traceroute were
> matching openflow rules with the incorrect destination ip,
> despite there being an openflow rule to undo the nat.
> Other packets in the established or new state matched the
> expected openflow rules.
>
> A git bisect between 5.15 and 6.2 showed that this change in
> behaviour was introduced by commit ebddb1404900. After the
> above patch is applied our routers perform nat correctly
> again for traceroute/mtr.

Acked-by: Xin Long <lucien.xin@...il.com>