Re: [PATCH net 0/7] Netfilter fixes for net

From: Paolo Abeni <pabeni@redhat.com>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org, davem@davemloft.net,
	 netdev@vger.kernel.org, kuba@kernel.org, edumazet@google.com,
	fw@strlen.de
Subject: Re: [PATCH net 0/7] Netfilter fixes for net
Date: Thu, 11 Apr 2024 13:58:37 +0200	[thread overview]
Message-ID: <828d9e79d2203cb8325f632bbcebd22e45f987c2.camel@redhat.com> (raw)
In-Reply-To: <ZhfMi7hL3TW0qmj7@calendula>

On Thu, 2024-04-11 at 13:42 +0200, Pablo Neira Ayuso wrote:
> On Thu, Apr 11, 2024 at 01:39:30PM +0200, Paolo Abeni wrote:
> > On Thu, 2024-04-11 at 13:28 +0200, Pablo Neira Ayuso wrote:
> > > Hi,
> > > 
> > > The following patchset contains Netfilter fixes for net:
> > > 
> > > Patches #1 and #2 add missing rcu read side lock when iterating over
> > > expression and object type list which could race with module removal.
> > > 
> > > Patch #3 prevents promisc packet from visiting the bridge/input hook
> > > 	 to amend a recent fix to address conntrack confirmation race
> > > 	 in br_netfilter and nf_conntrack_bridge.
> > > 
> > > Patch #4 adds and uses iterate decorator type to fetch the current
> > > 	 pipapo set backend datastructure view when netlink dumps the
> > > 	 set elements.
> > > 
> > > Patch #5 fixes removal of duplicate elements in the pipapo set backend.
> > > 
> > > Patch #6 flowtable validates pppoe header before accessing it.
> > > 
> > > Patch #7 fixes flowtable datapath for pppoe packets, otherwise lookup
> > >          fails and pppoe packets follow classic path.
> > > 
> > > Please, pull these changes from:
> > > 
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git nf-24-04-11
> > > 
> > > Thanks.
> > > 
> > > ----------------------------------------------------------------
> > > 
> > > The following changes since commit 19fa4f2a85d777a8052e869c1b892a2f7556569d:
> > > 
> > >   r8169: fix LED-related deadlock on module removal (2024-04-10 10:44:29 +0100)
> > > 
> > > are available in the Git repository at:
> > > 
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git tags/nf-24-04-11
> > > 
> > > for you to fetch changes up to 6db5dc7b351b9569940cd1cf445e237c42cd6d27:
> > > 
> > >   netfilter: flowtable: incorrect pppoe tuple (2024-04-11 12:14:10 +0200)
> > > 
> > > ----------------------------------------------------------------
> > > netfilter pull request 24-04-11
> > > 
> > > ----------------------------------------------------------------
> > > Florian Westphal (1):
> > >       netfilter: nft_set_pipapo: do not free live element
> > > 
> > > Pablo Neira Ayuso (4):
> > >       netfilter: br_netfilter: skip conntrack input hook for promisc packets
> > >       netfilter: nft_set_pipapo: walk over current view on netlink dump
> > >       netfilter: flowtable: validate pppoe header
> > >       netfilter: flowtable: incorrect pppoe tuple
> > > 
> > > Ziyang Xuan (2):
> > >       netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()
> > >       netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()
> > > 
> > >  include/net/netfilter/nf_flow_table.h      | 12 +++++++++++-
> > >  include/net/netfilter/nf_tables.h          | 14 ++++++++++++++
> > >  net/bridge/br_input.c                      | 15 +++++++++++----
> > >  net/bridge/br_netfilter_hooks.c            |  6 ++++++
> > >  net/bridge/br_private.h                    |  1 +
> > >  net/bridge/netfilter/nf_conntrack_bridge.c | 14 ++++++++++----
> > >  net/netfilter/nf_flow_table_inet.c         |  3 ++-
> > >  net/netfilter/nf_flow_table_ip.c           | 10 ++++++----
> > >  net/netfilter/nf_tables_api.c              | 22 ++++++++++++++++++----
> > >  net/netfilter/nft_set_pipapo.c             | 19 ++++++++++++-------
> > >  10 files changed, 91 insertions(+), 25 deletions(-)
> > 
> > Whoops, I'm finishing testing right now todays PR, I hope it's not a
> > big issue if this lands later?
> 
> Apologies, I am working at full steam here, I could not deliver any sooner.

I'm sorry, I was likely unclear, the above was just a question (not a
complain): do you have strong preference for these fixes to land into
today's PR? (the answer is unclear to me)

Thanks!

Paolo