Re: [PATCH nf] netfilter: nft_set_pipapo: don't leak bad clone into future transaction

[Florian Westphal <fw@strlen.de>]

Stefano Brivio <sbrivio@redhat.com> wrote:
> On Tue, 16 Jun 2026 21:19:34 +0200
> Florian Westphal <fw@strlen.de> wrote:
> 
> > On memory allocation failure the cloned nft_pipapo_match can enter a bad
> > state:
> >  - some fields can have their lookup tables resized while others did
> >    not
> >  - bits might have been toggled
> >  - scratch map can be undersized which also means m->bsize_max can be
> >    lower than what is required
> 
> If I understand it correctly, this is about pipapo_realloc_scratch()
> failing to allocate memory for per-CPU scratch maps but
> pipapo_maybe_clone() succeeding, right?

Yes.

> I don't see anything wrong with this approach, but I guess there might
> be a more obvious alternative, even though I didn't really think this
> through: undo what we did in nft_pipapo_insert() up to that point
> (perhaps calling nft_pipapo_delete() with a particular argument).

Yes, that is the laternative, return the cloned copy to a state where it
is identical to the state it had at function start.

> I can try to get to this in the next few days (I would have some ideas
> about testing, see below), but I suppose we want a fix quickly if that's
> really the case so I'm actually fine with this, with one nit, also
> reported below.

I don't mind, this can wait if you prefer to undo the state.