Re: nft_set_pipapo: UAF and double free from a stranded GC batch in the 5.15.y / 6.1.y / 6.6.y backports of 9df95785d3d8

Re: nft_set_pipapo: UAF and double free from a stranded GC batch in the 5.15.y / 6.1.y / 6.6.y backports of 9df95785d3d8

[Greg KH]

On Mon, Aug 03, 2026 at 09:19:28PM +0300, Fahad Alharbi wrote:
> Hello,
> 
> 6.6.148 backported the pipapo on-demand-clone series, but two commits from
> the original 2024 series were not included.  Two consequences are visible in
> the source.  Both are straightforward to confirm; no reproducer is needed.
> 
> Requested trees: 6.6.y
> 
> Missing commits:
> 
>   8b8a2417558c ("netfilter: nft_set_pipapo: prepare destroy function for
>                  on-demand clone")
>   532aec7e878b ("netfilter: nft_set_pipapo: remove dirty flag")
> 
> Both are Florian Westphal, 2024-04-25, and both are present in 6.10.y
> through 7.1.y and in mainline.  Neither is in 6.6.y.

That is because they do not cleanly apply there.  Can you provide
working backports for that tree, and any other older tree that you think
needs it, so we can queue them up?

thanks,

greg k-h

Re: nft_set_pipapo: UAF and double free from a stranded GC batch in the 5.15.y / 6.1.y / 6.6.y backports of 9df95785d3d8

[Sasha Levin]

On Tue, Aug 04, 2026 at 08:01:12AM +0200, Greg KH wrote:
>> Missing commits:
>>
>>   8b8a2417558c ("netfilter: nft_set_pipapo: prepare destroy function for
>>                  on-demand clone")
>>   532aec7e878b ("netfilter: nft_set_pipapo: remove dirty flag")
>
> That is because they do not cleanly apply there.  Can you provide
> working backports for that tree, and any other older tree that you think
> needs it, so we can queue them up?

Backports of those two commits would only cover 6.6.y, so they do not
close the report on their own. The per-tree picture is:

- 6.6.y: yes, it needs both. Its dependency chain pulled in the middle of
  the 2024 on-demand-clone series but skipped 8b8a2417558c immediately
  before it and 532aec7e878b immediately after.

- 6.1.y and 5.15.y: they never took the on-demand-clone series at all, so
  those two commits do not apply there even in principle. They need a
  structurally different, stable-only fix: make pipapo_gc_queue()
  unconditional so the batch that pipapo_gc_scan() already allocated and
  put on priv->gc_head cannot be stranded by the early returns sitting
  between the two calls.

-- 
Thanks,
Sasha