linux-kernel - Re: [PATCH v2 RFC 7/7] crypto: implement KFuzzTest targets for PKCS7 and RSA parsing

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANgxf6xCfk9uDsGgqWqociv0Q2Ngu0_GBR0vzWHwOAowsO+CVw@mail.gmail.com>
Date: Thu, 4 Sep 2025 22:20:56 +0200
From: Ethan Graham <ethan.w.s.graham@...il.com>
To: Ignat Korchagin <ignat@...udflare.com>
Cc: ethangraham@...gle.com, glider@...gle.com, andreyknvl@...il.com, 
	brendan.higgins@...ux.dev, davidgow@...gle.com, dvyukov@...gle.com, 
	jannh@...gle.com, elver@...gle.com, rmoar@...gle.com, shuah@...nel.org, 
	tarasmadan@...gle.com, kasan-dev@...glegroups.com, kunit-dev@...glegroups.com, 
	linux-kernel@...r.kernel.org, linux-mm@...ck.org, dhowells@...hat.com, 
	lukas@...ner.de, herbert@...dor.apana.org.au, davem@...emloft.net, 
	linux-crypto@...r.kernel.org
Subject: Re: [PATCH v2 RFC 7/7] crypto: implement KFuzzTest targets for PKCS7
 and RSA parsing

On Wed, Sep 3, 2025 at 10:58 AM Ignat Korchagin <ignat@...udflare.com> wrote:
> nit: can I ask for another real example? AFAIK this subsystem is
> rarely used (at least directly by users). However, one user-controlled
> widely used parser terrifies me: load_script() function from
> binfmt_script.c, which parses the shebang line for scripts. I would
> really like to see what this framework can do to fuzz that.

Thanks for the suggestion! It looks like a promising target.

> I'm a bit worried about the scalability of defining one (visible)
> config option per fuzz file/module. Is there a use-case, where a user
> would want to enable some targets, but not the others? Can it be
> unconditionally enabled and compiled only if CONFIG_KFUZZTEST=y?

That's a good point. I agree it's best to enable them all by default if
CONFIG_KFUZZTEST=y. A fuzzer can pick and choose which targets
it wants to fuzz so there's no downside there. My original thought was
to maintain consistency with how KUnit tests are built, but since
KFuzzTest targets aren't executed directly it makes sense to diverge
here.