Re: [PATCH net 00/13] Netfilter/IPVS fixes for net

Pablo Neira Ayuso <[email protected]>
Newsgroups gmane.linux.network,gmane.comp.security.firewalls.netfilter.devel
Message-ID <anugqXmnyKSMPl_w@chamomile>
On Tue, Aug 11, 2026 at 10:23:33PM +0200, Florian Westphal wrote:
> Jakub Kicinski <[email protected]> wrote:
> > On Mon, 10 Aug 2026 21:06:08 +0200 Pablo Neira Ayuso wrote:
> > > The following patchset contains Netfilter/IPVS fixes for net. Still
> > > large batch for this late -rc cycle but at least have of these fixes in
> > > this batch have been cooking for several weeks before:
> > 
> > Does any of the AI-detected issues seem concerning?
> > 
> > https://netdev-ai.bots.linux.dev/sashiko/#/patchset/[email protected]
> 
> Only commenting on those patches that I worked on or commented during
> review:
> 
> Patch 6: [PATCH net 06/13] netfilter: nf_conntrack: defer invalid log until after unlock
> 
> Its fine.  This is for debugging.  We could restore the removed info if
> anyone needs it, I even was about to suggest to original author to
> simply remove the invalid logging but decided against it (since you can
> log the packet to userspace via nfnetlink).  I prefer the simpler
> version that doesn't snapshot data while under lock.
> 
> Patch 7: [PATCH net 07/13] netfilter: nfnetlink_log: wait for rcu grace period before freeing pernet state
> 
> Yes, one could have added this Fixes tag or Cc stable to the patch.
> Don't think this warrants a respin by itself.
> 
> Patch 12: [PATCH net 12/13] netfilter: ipset: fix list type element drift bug
> 
> Even if the ordering is "wrong", the patch that
> added it is ancient (even in RHEL7) so its long established behaviour.
> 
> ipset test suite also has test for this and those tests pass, so
> changing kernel behaviour will need to adjust (old..) test cases as
> well.

Patch 10: [PATCH net 10/13] netfilter: nf_tables_offload: suppress WARN_ON_ONCE for ENOMEM in abort path

This is known issue and I've been working on a patch to address what
sashiko reports, basically, in case hardware offload is enabled,
errors should also rollback to the previous state.

There seem to be a path with hardware offload indirect flow block that
is buggy because ENOMEM is propagated as EOPNOTSUPP.

I need to follow up.

Patch 11: [PATCH net 11/13] netfilter: flowtable: publish GC-visible tuple last

Sashiko indicates that this needs a follow up because hardware offload
can still trigger a race with GC.

This also needs a follow up.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.