linux-kernel - Re: [PATCH v4 0/6] 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] [day] [month] [year] [list]

Message-ID: <CAG_fn=URHwuOuF_RNyxDCJZmjAFKSf4kHau6uTsFFPrTB=3-Kw@mail.gmail.com>
Date: Fri, 30 Jan 2026 12:13:49 +0100
From: Alexander Potapenko <glider@...gle.com>
To: shuah@...nel.org, skhan@...uxfoundation.org
Cc: akpm@...ux-foundation.org, 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, ebiggers@...nel.org, elver@...gle.com, 
	gregkh@...uxfoundation.org, herbert@...dor.apana.org.au, ignat@...udflare.com, 
	jack@...e.cz, Ethan Graham <ethan.w.s.graham@...il.com>, 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, 
	mcgrof@...nel.org, rmoar@...gle.com, sj@...nel.org, tarasmadan@...gle.com, 
	wentaoz5@...inois.edu
Subject: Re: [PATCH v4 0/6] KFuzzTest: a new kernel fuzzing framework

On Tue, Jan 20, 2026 at 3:26 PM Alexander Potapenko <glider@...gle.com> wrote:
>
> On Mon, Jan 12, 2026 at 8:28 PM Ethan Graham <ethan.w.s.graham@...il.com> 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.
> >
> > Following feedback from the Linux Plumbers Conference and mailing list
> > discussions, this version of the framework has been significantly
> > simplified. It now focuses exclusively on handling raw binary inputs,
> > removing the complexity of the custom serialization format and DWARF
> > parsing found in previous iterations.
>
> Thanks, Ethan!
> I left some comments, but overall I think we are almost there :)
>
> A remaining open question is how to handle concurrent attempts to
> write data to debugfs.
> Some kernel functions may not support reentrancy, so we'll need to
> either document this limitation or implement proper per-test case
> locking.

Hi Shuah, I wanted to bring this series to your attention.
There are some comments to be addressed in v5, but overall, do you
think the code qualifies as "having no dependency on syzkaller"?

Thanks!