Re: [PATCH] netfilter: nft_dynset: reject DELETE op when set lacks ->delete
From: Florian Westphal
Date: Sun Nov 08 2026 - 21:36:57 EST
Noah Weinberger <NoahWeinberger2003@xxxxxxxxx> 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.