Re: [PATCH] netfilter: nft_dynset: reject DELETE op when set lacks ->delete

[Florian Westphal <fw@strlen.de>]

Noah Weinberger <NoahWeinberger2003@proton.me> wrote:
> Hello,
> 
> nft_dynset_init() checks that the referenced set implements ->update,
> but for NFT_DYNSET_OP_DELETE the packet path calls set->ops->delete
> unconditionally. Today the only set type with ->update (nft_set_hash)
> also implements ->delete, so the call is always valid - but any future
> set type implementing ->update without ->delete turns a rule evaluation
> into a NULL function call.
> 
> Reject the DELETE op at init time when ->delete is missing, next to the
> existing ->update check.
> 
> Affected version/commit: mainline fa4ad798f6f681031775266044ba1b0cf3c670bd (v7.4-rc1, 2026-11-07), net/netfilter/nft_dynset.c:98-101 (eval), 209-217 (init).
> Longstanding asymmetry.
> 
> This was found during an assisted (AI-supported) static source review of
> mainline fa4ad798f6f681031775266044ba1b0cf3c670bd (v7.4-rc1, 2026-11-07); every code path cited below was re-verified by the
> reporter against that tree. The patch below has NOT been compiled and has
> NOT been runtime tested, and no reproducer was produced - the triggering
> conditions are described above instead. Please treat this as a report for
> verification rather than a battle-tested fix.

This would have been fine 1 year ago but we no longer have resources
and time to reproduce and verify such "fixes".

Ask your LLM for a reproducer, run it, show a minimal backtrace.
We have LLMs too and we can use them to create enough usless and
time-consuming tasks as-is.

I have a db of +1k reports just like this one.