Re: [PATCH v3 00/10] KFuzzTest: a new kernel fuzzing framework

[Alexander Potapenko <glider@google.com>]

On Wed, Dec 17, 2025 at 10:54 AM David Gow <davidgow@google.com> wrote:
>
> On Sat, 13 Dec 2025 at 08:07, Shuah Khan <skhan@linuxfoundation.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.