Message-ID: <cbc99cb2-4415-4757-8808-67bf7926fed4@linuxfoundation.org>
Date: Fri, 12 Dec 2025 17:06:59 -0700
From: Shuah Khan <skhan@...uxfoundation.org>
To: Ethan Graham <ethan.w.s.graham@...il.com>, glider@...gle.com
Cc: andreyknvl@...il.com, andy@...nel.org, andy.shevchenko@...il.com,
 brauner@...nel.org, brendan.higgins@...ux.dev, davem@...emloft.net,
 davidgow@...gle.com, 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, Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH v3 00/10] KFuzzTest: a new kernel fuzzing framework

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.

Until such time, we can hold off on merging this code as is.
  
thanks,
-- Shuah

Powered by blists - more mailing lists