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 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/