mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Westphal <fw@strlen.de>
Cc: Noah Weinberger <NoahWeinberger2003@proton.me>,
	"kadlec@netfilter.org" <kadlec@netfilter.org>,
	"netfilter-devel@vger.kernel.org"
	<netfilter-devel@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] netfilter: nft_dynset: reject DELETE op when set lacks ->delete
Date: Mon, 9 Nov 2026 11:11:41 +0100	[thread overview]
Message-ID: <avGcXYd1ii96m8L0@chamomile> (raw)
In-Reply-To: <avExLOsc3ZWRF5hh@strlen.de>

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

      reply	other threads:[~2026-11-09 10:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-08 22:32 Noah Weinberger
2026-11-09  2:34 ` Florian Westphal
2026-11-09 10:11   ` Pablo Neira Ayuso [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=avGcXYd1ii96m8L0@chamomile \
    --to=pablo@netfilter.org \
    --cc=NoahWeinberger2003@proton.me \
    --cc=fw@strlen.de \
    --cc=kadlec@netfilter.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®