Re: Question about "stateless or low-state functions" in KFuzzTest doc

[Ethan Graham <ethan.w.s.graham@gmail.com>]

On Fri, Mar 6, 2026 at 12:04 PM Jiakai Xu <jiakaipeanut@gmail.com> wrote:
>
> Hi Ethan,

Hi Jiakai,

> Thanks for the detailed explanation.
>
> Would it be fair to say that KFuzzTest is not well suited for testing
> kernel functions that are heavily influenced by or have a significant
> impact on kernel state?

With the current fuzzer support (see the PR in the syzkaller repo [1])
this is a fair assessment, but with a caveat.

It really depends on how you are fuzzing. KFuzzTest itself is just the
conduit. Whether or not your fuzzer can meaningfully reproduce
bugs/crashes related to complex state is somewhat out of KFuzzTest's
hands. However as of v4 the framework only supports blob-based
fuzzing, I would advise against targeting heavily stateful functions right
now. You are welcome to experiment to see if there is a way to meaningfully
fuzz more stateful functions, but with just binary buffers as inputs, I don't
reckon that there will be too many candidates.

> I agree with your point that "the goal of the framework is to fuzz real
> functions with realistic inputs." One thing I've been thinking about,
> though, is how we determine what counts as "realistic" input for a given
> function. If the generated inputs that a function would never actually
> receive in practice, we'd likely end up chasing false-positive crashes
> that don't represent real bugs.

I would argue that just because an input isn't "realistic" in the current
kernel context (i.e., the current upstream code only calls into the library
after performing sanity checks and/or validation) doesn't mean that a
crash isn't problematic.

Code can and does get reused and refactored over time. If an internal
parser can cause a panic or OOB access when handed certain inputs,
it is inherently fragile. Even if that code path is shielded today, it could
be exposed by a new caller tomorrow. Our baseline assumption here is
that if a function accepts a blob as input, it should be resilient to all types
of blobs.

However your concerns about false positives is justified, and something
that we have thought about. In previous iterations of this work, we relied
on a constraints system for encoding input semantics and performing
validation inside the fuzz harness. While we stepped back from that due
to its inherent complexity, instead favoring a more simple blob-only design,
adding constraints to better define "realistic" inputs is a good idea that may
need to be revisited in the future.

Hope this helps clarify the design philosphy!

[1] related syzkaller PR for KFuzzTest:
https://github.com/google/syzkaller/pull/6280

> Thanks,
> Jiakai
>
>
> On Fri, Mar 6, 2026 at 6:29 PM Ethan Graham <ethan.w.s.graham@gmail.com> wrote:
> >
> > On Fri, Mar 6, 2026 at 10:45 AM Jiakai Xu <jiakaipeanut@gmail.com> wrote:
> > >
> > > Hi Ethan and all,
> >
> > Hi Jiakai
> >
> > > I've been reading the KFuzzTest documentation patch (v4 3/6) with great
> > > interest. I have some questions about the scope and applicability of this
> > > framework that I'd like to discuss with the community.
> > >
> > > The documentation states:
> > > > It is intended for testing stateless or low-state functions that are
> > > > difficult to reach from the system call interface, such as routines
> > > > involved in file format parsing or complex data transformations.
> > >
> > > I'm trying to better understand what qualifies as a "stateless or
> > > low-state function" in the kernel context. How do we define or identify
> > > whether a kernel function is stateless or low-state?
> > >
> > > Also, I'm curious - what proportion of kernel functions would we
> > > estimate falls into this category?
> >
> > I would define it based on "practical heuristics". A function is probably a
> > good candidate for KFuzzTest if it fits these loose criteria:
> >
> > - Minimal setup: KFuzzTest currently supports blob-based fuzzing, so the
> >   function should consume raw data (or a thin wrapper struct) and not
> >   require a complex web of pre-initialized objects or deep call-chain
> >   prerequisites.
> > - Manageable teardown: if the function allocates memory or creates
> >   objects, the fuzzing harness must be able to cleanly free or revert
> >   that state before the next iteration. An example of this can be found
> >   in the pkcs7 example in patch 5/6 [1].
> > - Non-destructive global impact: it's okay if the function touches global
> >   state in minor ways (e.g., writing to the OID registry logs as is done
> >   by the crypto/ functions that are fuzzed by the harnesses in patch 5/6),
> >   but what matters is that the kernel isn't left in a broken state before the
> >   next fuzzing iteration, meaning no leaked global locks, no corrupted
> >   shared data structures, and no deadlocks.
> >
> > These loose criteria are just suggestions, as you can technically fuzz
> > anything that you want to - KFuzzTest won't stop you. The danger is
> > that the kernel isn't designed to have raw userspace inputs shoved
> > into deep stateful functions out of nowhere. If a harness or function
> > relies on complex ad-hoc state management or strict preconditions,
> > fuzzing it out of context will likely just result in false positives, panics,
> > and ultimately bogus harnesses.
> >
> > The goal of the framework is to fuzz real functions with realistic inputs
> > without accidentally breaking other parts of the kernel that the function
> > wasn't meant to touch. Therefore ideal targets (like the PKCS7 example)
> > are ones with minimal setup (just passing a blob), have manageable
> > teardown (like freeing a returned object on success) and don't
> > destructively impact global state (even if they do minor things like
> > printing to logs).
> >
> > That said, I'm curious to see what you come up with! I'm sure there are
> > other use cases that I haven't thought of.
> >
> > [1] PKCS7 message parser fuzzing harness:
> > https://lore.kernel.org/all/20260112192827.25989-6-ethan.w.s.graham@gmail.com/