linux-kernel - Re: [PATCH v3 00/10] 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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAG_fn=WvdKZgmkqa09kwLLH3P_j6GFYzopeD-PZ-Qt0-1KUaGw@mail.gmail.com>
Date: Wed, 17 Dec 2025 11:19:10 +0100
From: Alexander Potapenko <glider@...gle.com>
To: David Gow <davidgow@...gle.com>
Cc: Shuah Khan <skhan@...uxfoundation.org>, Ethan Graham <ethan.w.s.graham@...il.com>, 
	andreyknvl@...il.com, andy@...nel.org, andy.shevchenko@...il.com, 
	brauner@...nel.org, brendan.higgins@...ux.dev, davem@...emloft.net, 
	dhowells@...hat.com, dvyukov@...gle.com, elver@...gle.com, 
	herbert@...dor.apana.org.au, ignat@...udflare.com, jack@...e.cz, 
	jannh@...gle.com, johannes@...solutions.net, 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, 
	rmoar@...gle.com, shuah@...nel.org, sj@...nel.org, tarasmadan@...gle.com
Subject: Re: [PATCH v3 00/10] KFuzzTest: a new kernel fuzzing framework

On Wed, Dec 17, 2025 at 10:54 AM David Gow <davidgow@...gle.com> wrote:
>
> On Sat, 13 Dec 2025 at 08:07, Shuah Khan <skhan@...uxfoundation.org> wrote:
> >
> > On 12/4/25 07:12, Ethan Graham wrote:
> > > This patch series introduces KFuzzTest, a lightweight framework for
> > > creating in-kernel fuzz targets for internal kernel functions.
> > >
> > > The primary motivation for KFuzzTest is to simplify the fuzzing of
> > > low-level, relatively stateless functions (e.g., data parsers, format
> > > converters) that are difficult to exercise effectively from the syscall
> > > boundary. It is intended for in-situ fuzzing of kernel code without
> > > requiring that it be built as a separate userspace library or that its
> > > dependencies be stubbed out. Using a simple macro-based API, developers
> > > can add a new fuzz target with minimal boilerplate code.
> > >
> > > The core design consists of three main parts:
> > > 1. The `FUZZ_TEST(name, struct_type)` and `FUZZ_TEST_SIMPLE(name)`
> > >     macros that allow developers to easily define a fuzz test.
> > > 2. A binary input format that allows a userspace fuzzer to serialize
> > >     complex, pointer-rich C structures into a single buffer.
> > > 3. Metadata for test targets, constraints, and annotations, which is
> > >     emitted into dedicated ELF sections to allow for discovery and
> > >     inspection by userspace tools. These are found in
> > >     ".kfuzztest_{targets, constraints, annotations}".
> > >
> > > As of September 2025, syzkaller supports KFuzzTest targets out of the
> > > box, and without requiring any hand-written descriptions - the fuzz
> > > target and its constraints + annotations are the sole source of truth.
> > >
> > > To validate the framework's end-to-end effectiveness, we performed an
> > > experiment by manually introducing an off-by-one buffer over-read into
> > > pkcs7_parse_message, like so:
> > >
> > > - ret = asn1_ber_decoder(&pkcs7_decoder, ctx, data, datalen);
> > > + ret = asn1_ber_decoder(&pkcs7_decoder, ctx, data, datalen + 1);
> > >
> > > A syzkaller instance fuzzing the new test_pkcs7_parse_message target
> > > introduced in patch 7 successfully triggered the bug inside of
> > > asn1_ber_decoder in under 30 seconds from a cold start. Similar
> > > experiments on the other new fuzz targets (patches 8-9) also
> > > successfully identified injected bugs, proving that KFuzzTest is
> > > effective when paired with a coverage-guided fuzzing engine.
> > >
> >
> > As discussed at LPC, the tight tie between one single external user-space
> > tool isn't something I am in favor of. The reason being, if the userspace
> > app disappears all this kernel code stays with no way to trigger.
> >
> > Ethan and I discussed at LPC and I asked Ethan to come up with a generic way
> > to trigger the fuzz code that doesn't solely depend on a single users-space
> > application.
> >
>
> FWIW, the included kfuzztest-bridge utility works fine as a separate,
> in-tree way of triggering the fuzz code. It's definitely not totally
> standalone, but can be useful with some ad-hoc descriptions and piping
> through /dev/urandom or similar. (Personally, I think it'd be a really
> nice way of distributing reproducers.)
>
> The only thing really missing would be having the kfuzztest-bridge
> interface descriptions available (or, ideally, autogenerated somehow).
> Maybe a simple wrapper to run it in a loop as a super-basic
> (non-guided) fuzzer, if you wanted to be fancy.
>
> -- David

An alternative Ethan and I discussed was implementing only
FUZZ_TEST_SIMPLE for the initial commit.
It wouldn't even need the bridge tool, because the inputs are
unstructured, and triggering them would involve running `head -c N
/dev/urandom > /sys/kernel/debug/kfuzztest/TEST_NAME/input_simple`
This won't let us pass complex data structures from the userspace, but
we can revisit that when there's an actual demand for it.