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

[Florian Westphal <fw@strlen.de>]

Fernando Fernandez Mancera <fmancera@suse.de> wrote:
> On 10/17/25 1:51 PM, Florian Westphal wrote:
> > afl comes with a compiler frontend that can add instrumentation suitable
> > for running nftables via the "afl-fuzz" fuzzer.
> > 
> > This change adds a "--with-fuzzer" option to configure script and enables
> > specific handling in nftables and libnftables to speed up the fuzzing process.
> > It also adds the "--fuzzer" command line option.
> > 
> 
> Hi Florian, I think this is awesome. I have been playing with it since you
> posted this patch.. and found a couple of things already!

Great :)

> > In case a kernel splat is detected, the fuzzing process stops and all further
> > fuzzer attemps are blocked until reboot.
> > 
> I do not think this is what happens or I am maybe misunderstanding
> something.I got a kernel splat - soft lockup as the CPU was stuck for 40s
> (!). Anyway, kernel was then tainted but the fuzzer didn't stop it continued
> running but not executing the commands as kernel was tainted.. see the
> comments below.

Yes, I don't know how to stop it.  IIRC exit() just makes afl-fuzz resume
with next cycle.

> While this prevents the execution of the command, the input is already
> generated. See comments in main function.

Yes.  I just want it to stop burning cpu cycles if kernel is already
tainted.

> > +	buf = __AFL_FUZZ_TESTCASE_BUF;
> > +
> > +	while (__AFL_LOOP(UINT_MAX)) {
> > +		char *input;
> > +
> > +		len = __AFL_FUZZ_TESTCASE_LEN;  // do not use the macro directly in a call!
> > +
> > +		input = preprocess(buf, len);
> > +		if (!input)
> > +			continue;
> > +
> > +		/* buf is null terminated at this point */
> > +		if (!nft_afl_run_cmd(ctx, input))
> > +			continue;
> 
> If we get a kernel splat and kernel is tainted but continue running (soft
> lockup, warning..) the fuzzer won't stop, it won't execute more commands but
> it will generate inputs for hours.

Yes, it should not continue to burn cpu cycles.

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

> I have a server at home that I am not using.. I would love to automate a
> script to run this in multiple VMs and generate reports :)

Yes, that would be good.  Note that I still primarily use it with
netlink-ro mode to not exercise he kernel, its easy to make graph
validation (or abort path) take very long to finish.

There is still a patch series in the queue to limit jumps in nftables
and I did not yet have time in looking at the abort path, Its simply not
an issue for normal cases (you assume the input is going to be
committed...).  But for faster netlink-rw/knft fuzzing it would make
sense to look into async abort (like we do for commit cleanup).