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

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

[Noah Weinberger]

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.

Reported-by: Noah Weinberger <noahweinberger2003@proton.me>
---
diff --git a/net/netfilter/nft_dynset.c b/net/netfilter/nft_dynset.c
index fa4da69..5e2bbd0 100644
--- a/net/netfilter/nft_dynset.c
+++ b/net/netfilter/nft_dynset.c
@@ -216,6 +216,9 @@ static int nft_dynset_init(const struct nft_ctx *ctx,
 	if (priv->op > NFT_DYNSET_OP_DELETE)
 		return -EOPNOTSUPP;
 
+		if (priv->op == NFT_DYNSET_OP_DELETE && !set->ops->delete)
+			return -EOPNOTSUPP;
+
 	timeout = 0;
 	if (tb[NFTA_DYNSET_TIMEOUT] != NULL) {
 		if (!(set->flags & NFT_SET_TIMEOUT))

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

[Florian Westphal]

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.

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

[Pablo Neira Ayuso]

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

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).