On Wed, Dec 17, 2025 at 10:54 AM David Gow [off-list ref] wrote:

On Sat, 13 Dec 2025 at 08:07, Shuah Khan [off-list ref] wrote:

quoted

On 12/4/25 07:12, Ethan Graham wrote:

quoted

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.