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

From: Pablo Neira Ayuso

Date: Mon Nov 09 2026 - 05:16:29 EST


On Mon, Nov 09, 2026 at 03:34:20AM +0100, Florian Westphal wrote:
> 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.

Right.

The reporter has to proof this is not theoretical.

LLM might no "understand" that only sets with dynamic backends are
eligible.

And this patch points to the /dev/null tree: Submitter has to specify
if this is for nf.git (unlikely) or nf-next.git (maybe, just for
hardening).