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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CABVgOSkbV0idRzeMmsUEtDo=U5Tzqc116mt_=jqW-xsToec_wQ@mail.gmail.com>
Date: Wed, 17 Dec 2025 17:53:58 +0800
From: David Gow <davidgow@...gle.com>
To: Shuah Khan <skhan@...uxfoundation.org>
Cc: Ethan Graham <ethan.w.s.graham@...il.com>, glider@...gle.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 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

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5281 bytes)