Re: [PATCH nft v2] support for afl++ (american fuzzy lop++) fuzzer

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Mon, Oct 20, 2025 at 08:35:34PM +0200, Pablo Neira Ayuso wrote:
> On Mon, Oct 20, 2025 at 05:23:47PM +0200, Fernando Fernandez Mancera wrote:
> > 
> > 
> > On 10/20/25 4:24 PM, Florian Westphal wrote:
> > > Fernando Fernandez Mancera <fmancera@suse.de> wrote:
> > > > On 10/19/25 4:17 PM, Florian Westphal wrote:
> > > > > > In addition I noticed that when a kernel splat happens the ruleset that
> > > > > > triggered it isn't saved anywhere, it would be nice to save them so we have
> > > > > > a reproducer right away.
> > > > > 
> > > > > I had such code but removed it for this version.
> > > > > 
> > > > > I can send a followup patch to re-add it but I think that it is better
> > > > > for kernel fuzzing to extend knft acordingly, as nft is restricted by
> > > > > the input grammar wrt. the nonsense that it can create.
> > > > > 
> > > > 
> > > > That is fine for me, I still have pending to try knft which I might do
> > > > this week if I have time. If we do not want to save which ruleset
> > > > generated the kernel splat I would drop netlink-rw mode completely..
> > > 
> > > Hmmm.... I'm not sure on this.  It would be a bit of a silly limitation.
> > > Its not like -rw adds a huge chunk of code.
> > > 
> > > The store code wasn't too bad, back then I added some scripting for
> > > allow to e.g. call nft flush ruleset periodically and that was more code
> > > than strictly needed for pure nft (-ro mode) fuzzing.
> > > 
> > > > Yes, it seems we found the same issue. I do not have a solution on the
> > > > control plane although I was about to send this patch for data plane.
> > > > 
> > > > diff --git a/net/netfilter/nf_tables_core.c b/net/netfilter/nf_tables_core.c
> > > > index 6557a4018c09..ddc4943d082c 100644
> > > > --- a/net/netfilter/nf_tables_core.c
> > > > +++ b/net/netfilter/nf_tables_core.c
> > > > @@ -251,10 +251,10 @@ nft_do_chain(struct nft_pktinfo *pkt, void *priv)
> > > >    {
> > > >           const struct nft_chain *chain = priv, *basechain = chain;
> > > >           const struct net *net = nft_net(pkt);
> > > > +       unsigned int stackptr = 0, jumps = 0;
> > > >           const struct nft_expr *expr, *last;
> > > >           const struct nft_rule_dp *rule;
> > > >           struct nft_regs regs;
> > > > -       unsigned int stackptr = 0;
> > > >           struct nft_jumpstack jumpstack[NFT_JUMP_STACK_SIZE];
> > > >           bool genbit = READ_ONCE(net->nft.gencursor);
> > > >           struct nft_rule_blob *blob;
> > > > @@ -314,6 +314,9 @@ nft_do_chain(struct nft_pktinfo *pkt, void *priv)
> > > > 
> > > >           switch (regs.verdict.code) {
> > > >           case NFT_JUMP:
> > > > +               jumps++;
> > > > +               if (WARN_ON_ONCE(jumps > 256))
> > > > +                       return NF_DROP;
> > > >                   if (WARN_ON_ONCE(stackptr >= NFT_JUMP_STACK_SIZE))
> > > >                           return NF_DROP;
> > > >                   jumpstack[stackptr].rule = nft_rule_next(rule);
> > > > 
> > > > Currently with enough jumps chained together and traffic generated, CPU
> > > > can get stuck on nft_do_chain() triggering a kernel splat. If there is a
> > > > solution on data plane it would be much better than this of course.
> > > 
> > > There is this patch:
> > > https://patchwork.ozlabs.org/project/netfilter-devel/patch/20250728040315.1014454-1-brady.1345@gmail.com/
> > > 
> > > I planned to push it upstream in this merge window.
> > 
> > This looks quite good. I tested it and seems to solve the problem, great!
> 
> This patch emits a WARN_ON_ONCE.
> 
> Can this be controlled from control plane instead?

Oh well, you refer to the patch that checks this from control plane.

I remember an issue with abort path, has this been addressed?