Re: [PATCH nf] netfilter: nf_tables: inconditionally bump set->nelems before insertion

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Tue, Feb 24, 2026 at 07:55:26PM +0100, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > In case that the set is full, a new element gets published then removed
> > without waiting for the RCU grace period, while RCU reader can be
> > walking over it already.
> > 
> > To address this issue, add the element transaction even if set is full,
> > but toggle the set_full flag to report -ENFILE so the abort path safely
> > unwinds the set to its previous state.
> > 
> > As for element updates, decrement set->nelems to restore it.
> 
> While I think this patch is correct and fixes the bug, I would
> prefer the one-liner from Inseo An, it will be easier to backport it.
>
> I propose we do this:
> 
> I do a nf pull request now, with Inseos version.
> 
> Then, after that has been merged back into nf-next, rebase this patch
> on top of it and apply it.
> 
> Then, in 2nd step, also rework 71e99ee20fc3 ("netfilter: nf_tables: fix use-after-free in nf_tables_addchain()")
> to follow same pattern as in your patch, i.e. defer the release to the
> abort path instead.  This way we have easier to backport fixes while we
> establish this new pattern of adding to-be-aborted transaction objects to
> the list.
> 
> Makes sense to you?

My concern is that this slows down a scenario that is possible, ie.
adding an element to a full set.

... compared to 71e99ee20fc3, where it is almost *impossible* to reach
that synchronize_rcu() in a real use-case since you have to register
1024 basechains.