netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Aaron Conole <aconole@redhat.com>
To: Simon Horman <horms@kernel.org>
Cc: Brad Cowie <brad@faucet.nz>,
	 netdev@vger.kernel.org, dev@openvswitch.org,  fw@strlen.de,
	 linux-kernel@vger.kernel.org, kadlec@netfilter.org,
	 edumazet@google.com, netfilter-devel@vger.kernel.org,
	 kuba@kernel.org,  pabeni@redhat.com, davem@davemloft.net,
	 pablo@netfilter.org,  Xin Long <lucien.xin@gmail.com>,
	 coreteam@netfilter.org
Subject: Re: [PATCH net] netfilter: nf_nat: fix action not being set for all ct states
Date: Tue, 02 Jan 2024 10:10:15 -0500	[thread overview]
Message-ID: <f7tle97eppk.fsf@redhat.com> (raw)
In-Reply-To: <20231223211306.GA215659@kernel.org> (Simon Horman's message of "Sat, 23 Dec 2023 21:13:06 +0000")

Simon Horman <horms@kernel.org> writes:

> + Xin Long <lucien.xin@gmail.com>
>   Aaron Conole <aconole@redhat.com>
>   coreteam@netfilter.org
>
> On Fri, Dec 22, 2023 at 11:43:11AM +1300, Brad Cowie wrote:
>> This fixes openvswitch's handling of nat packets in the related state.
>> 
>> In nf_ct_nat_execute(), which is called from nf_ct_nat(), ICMP/ICMPv6
>> packets in the IP_CT_RELATED or IP_CT_RELATED_REPLY state, which have
>> not been dropped, will follow the goto, however the placement of the
>> goto label means that updating the action bit field will be bypassed.
>> 
>> This causes ovs_nat_update_key() to not be called from ovs_ct_nat()
>> which means the openvswitch match key for the ICMP/ICMPv6 packet is not
>> updated and the pre-nat value will be retained for the key, which will
>> result in the wrong openflow rule being matched for that packet.
>> 
>> Move the goto label above where the action bit field is being set so
>> that it is updated in all cases where the packet is accepted.
>> 
>> Fixes: ebddb1404900 ("net: move the nat function to nf_nat_ovs for ovs and tc")
>> Signed-off-by: Brad Cowie <brad@faucet.nz>
>
> Thanks Brad,
>
> I agree with your analysis and that the problem appears to
> have been introduced by the cited commit.
>
> I am curious to know what use case triggers this /
> why it when unnoticed for a year.
>
> But in any case, this fix looks good to me.
>
> Reviewed-by: Simon Horman <horms@kernel.org>
>
>> ---

LGTM.  I guess we should try to codify the specific flows that were used
to flag this into the ovs selftest - we clearly have a missing case
after NAT lookup.

I'll add it to my (ever growing) list.

Meanwhile,

Acked-by: Aaron Conole <aconole@redhat.com>

>>  net/netfilter/nf_nat_ovs.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/net/netfilter/nf_nat_ovs.c b/net/netfilter/nf_nat_ovs.c
>> index 551abd2da614..0f9a559f6207 100644
>> --- a/net/netfilter/nf_nat_ovs.c
>> +++ b/net/netfilter/nf_nat_ovs.c
>> @@ -75,9 +75,10 @@ static int nf_ct_nat_execute(struct sk_buff *skb, struct nf_conn *ct,
>>  	}
>>  
>>  	err = nf_nat_packet(ct, ctinfo, hooknum, skb);
>> +out:
>>  	if (err == NF_ACCEPT)
>>  		*action |= BIT(maniptype);
>> -out:
>> +
>>  	return err;
>>  }
>>  
>> -- 
>> 2.34.1
>> 
>> _______________________________________________
>> dev mailing list
>> dev@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>> 


  parent reply	other threads:[~2024-01-02 15:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-21 22:43 [PATCH net] netfilter: nf_nat: fix action not being set for all ct states Brad Cowie
2023-12-23 21:13 ` Simon Horman
2023-12-24  2:47   ` Brad Cowie
2023-12-28 15:59     ` Xin Long
2024-01-02 15:10   ` Aaron Conole [this message]
2024-01-03 10:26     ` Pablo Neira Ayuso
2024-01-04  5:04     ` Brad Cowie

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=f7tle97eppk.fsf@redhat.com \
    --to=aconole@redhat.com \
    --cc=brad@faucet.nz \
    --cc=coreteam@netfilter.org \
    --cc=davem@davemloft.net \
    --cc=dev@openvswitch.org \
    --cc=edumazet@google.com \
    --cc=fw@strlen.de \
    --cc=horms@kernel.org \
    --cc=kadlec@netfilter.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucien.xin@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pablo@netfilter.org \
    /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;
as well as URLs for NNTP newsgroup(s).