linux-kernel - Re: [PATCH v4 0/6] KFuzzTest: a new kernel fuzzing framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <27c35b1f39c4cfaaf3b8322bbeb793c268fe4b6e.camel@sipsolutions.net>
Date: Wed, 14 Jan 2026 13:37:26 +0100
From: Johannes Berg <johannes@...solutions.net>
To: Ethan Graham <ethan.w.s.graham@...il.com>, glider@...gle.com
Cc: akpm@...ux-foundation.org, andreyknvl@...il.com, andy@...nel.org, 
	andy.shevchenko@...il.com, brauner@...nel.org, brendan.higgins@...ux.dev, 
	davem@...emloft.net, davidgow@...gle.com, dhowells@...hat.com,
 dvyukov@...gle.com, 	ebiggers@...nel.org, elver@...gle.com,
 gregkh@...uxfoundation.org, 	herbert@...dor.apana.org.au,
 ignat@...udflare.com, jack@...e.cz, jannh@...gle.com, 
	kasan-dev@...glegroups.com, kees@...nel.org, kunit-dev@...glegroups.com, 
	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org, 	lukas@...ner.de, mcgrof@...nel.org, shuah@...nel.org,
 sj@...nel.org, 	skhan@...uxfoundation.org, tarasmadan@...gle.com,
 wentaoz5@...inois.edu, 	raemoar63@...il.com
Subject: Re: [PATCH v4 0/6] KFuzzTest: a new kernel fuzzing framework

Hi Ethan,

> I wanted to check if this v4 aligns with your previous feedback regarding
> the tight coupling with userspace tools.
> 
> The custom serialization has been removed entirely along with the bridge
> tool. This series now focuses exclusively on passing raw binary inputs
> via debugfs with the FUZZ_TEST_SIMPLE macro.
> 
> The decoupling eliminates any dependency on syzkaller and should help
> remove some of the blockers that you previously encountered when
> considering integration with other fuzzing engines.
> 
> Does this simplified design look closer to what you need?

Thanks for reaching out!

We're doing some changes here and I also need to focus on some WiFi
features, so I don't really know when (if?) I'll continue working on
this, but yes, this definitely aligns much better with what I had in
mind.

FWIW, maybe for new people on the thread, last time I was considering
building ARCH=um in a way that it would run into a (selectable) fuzz
test, fork, and then feed it fuzzer input coming from honggfuzz [1]. I'm
handwaving a bit [2], but this would basically bypass userspace
completely and let us fuzz any of the tests in the kernel with "reset"
for each fuzzing round.

[1] selected because it's compatible with what the kernel does now with
kcov for coverage feedback, afl++ currently cannot deal with this for
some reason

[2] because I hadn't quite figured out how to make UML a single thread
only and get rid of the userspace running inside of it

Regardless, definitely yes, I think the design is much simpler and even
if I don't end up integrating honggfuzz this specific way, I do believe
it will make it much simpler (and more performant) to integrate with
other fuzzers.

johannes