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