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