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

[Jiakai Xu]

Hi Ethan,

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?

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.

Thanks,
Jiakai


On Fri, Mar 6, 2026 at 6:29 PM Ethan Graham <ethan.w.s.graham@xxxxxxxxx> wrote:
>
> On Fri, Mar 6, 2026 at 10:45 AM Jiakai Xu <jiakaipeanut@xxxxxxxxx> 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@xxxxxxxxx/