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

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