From: Ethan Graham <ethangraham@google.com>
Add a KFuzzTest fuzzer for the parse_xy() function, located in a new
file under /drivers/auxdisplay/tests.
To validate the correctness and effectiveness of this KFuzzTest target,
a bug was injected into parse_xy() like so:
drivers/auxdisplay/charlcd.c:179
- s = p;
+ s = p + 1;
Although a simple off-by-one bug, it requires a specific input sequence
in order to trigger it, thus demonstrating the power of pairing
KFuzzTest with a coverage-guided fuzzer like syzkaller.
Signed-off-by: Ethan Graham <ethangraham@google.com>
Signed-off-by: Ethan Graham <ethan.w.s.graham@gmail.com>
Acked-by: Alexander Potapenko <glider@google.com>
---
PR v3:
- Remove conditional inclusion of charlcd_kfuzz.c from charlcd.c, as
requested by Andy Shevchenko.
- Update auxdisplay Makefile to conditionally build charlcd_kfuzz.c when
CONFIG_KFUZZTEST=y, as suggested by Lukas Wunner and Andy Shevchenko.
- Foward declare parse_xy in charlcd_kfuzz.c.
---
---
drivers/auxdisplay/Makefile | 3 +++
drivers/auxdisplay/tests/charlcd_kfuzz.c | 22 ++++++++++++++++++++++
2 files changed, 25 insertions(+)
create mode 100644 drivers/auxdisplay/tests/charlcd_kfuzz.c
diff --git a/drivers/auxdisplay/Makefile b/drivers/auxdisplay/Makefile
index f5c13ed1cd4f..af00b0a173de 100644
--- a/drivers/auxdisplay/Makefile
+++ b/drivers/auxdisplay/Makefile
@@ -6,6 +6,9 @@
obj-$(CONFIG_ARM_CHARLCD) += arm-charlcd.o
obj-$(CONFIG_CFAG12864B) += cfag12864b.o cfag12864bfb.o
obj-$(CONFIG_CHARLCD) += charlcd.o
+ifeq ($(CONFIG_KFUZZTEST),y)
+CFLAGS_charlcd.o += -include $(src)/tests/charlcd_kfuzz.c
+endif
obj-$(CONFIG_HD44780_COMMON) += hd44780_common.o
obj-$(CONFIG_HD44780) += hd44780.o
obj-$(CONFIG_HT16K33) += ht16k33.o
diff --git a/drivers/auxdisplay/tests/charlcd_kfuzz.c b/drivers/auxdisplay/tests/charlcd_kfuzz.c
new file mode 100644
index 000000000000..3adf510f4356
--- /dev/null
+++ b/drivers/auxdisplay/tests/charlcd_kfuzz.c
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * charlcd KFuzzTest target
+ *
+ * Copyright 2025 Google LLC
+ */
+#include <linux/kfuzztest.h>
+
+struct parse_xy_arg {
+ const char *s;
+};
+
+static bool parse_xy(const char *s, unsigned long *x, unsigned long *y);
+
+FUZZ_TEST(test_parse_xy, struct parse_xy_arg)
+{
+ unsigned long x, y;
+
+ KFUZZTEST_EXPECT_NOT_NULL(parse_xy_arg, s);
+ KFUZZTEST_ANNOTATE_STRING(parse_xy_arg, s);
+ parse_xy(arg->s, &x, &y);
+}
--
2.51.0Hi Ethan, kernel test robot noticed the following build errors: [auto build test ERROR on akpm-mm/mm-nonmm-unstable] [also build test ERROR on herbert-cryptodev-2.6/master herbert-crypto-2.6/master linus/master v6.18] [cannot apply to next-20251205] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Ethan-Graham/mm-kasan-implement-kasan_poison_range/20251204-222307 base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-nonmm-unstable patch link: https://lore.kernel.org/r/20251204141250.21114-10-ethan.w.s.graham%40gmail.com patch subject: [PATCH 09/10] drivers/auxdisplay: add a KFuzzTest for parse_xy() config: i386-allmodconfig (https://download.01.org/0day-ci/archive/20251208/202512080828.Gxjg6av3-lkp@intel.com/config) compiler: gcc-14 (Debian 14.2.0-19) 14.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251208/202512080828.Gxjg6av3-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202512080828.Gxjg6av3-lkp@intel.com/ All errors (new ones prefixed by >>, old ones prefixed by <<): >> ERROR: modpost: "kfuzztest_write_cb_common" [drivers/auxdisplay/charlcd.ko] undefined! >> ERROR: modpost: "kfuzztest_parse_and_relocate" [drivers/auxdisplay/charlcd.ko] undefined! >> ERROR: modpost: "record_invocation" [drivers/auxdisplay/charlcd.ko] undefined! -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
On Thu, Dec 4, 2025 at 4:13 PM Ethan Graham <ethan.w.s.graham@gmail.com> wrote:
>
> From: Ethan Graham <ethangraham@google.com>
>
> Add a KFuzzTest fuzzer for the parse_xy() function, located in a new
> file under /drivers/auxdisplay/tests.
drivers/...
(no leading /)
> To validate the correctness and effectiveness of this KFuzzTest target,
> a bug was injected into parse_xy() like so:
>
> drivers/auxdisplay/charlcd.c:179
> - s = p;
> + s = p + 1;
>
> Although a simple off-by-one bug, it requires a specific input sequence
> in order to trigger it, thus demonstrating the power of pairing
> KFuzzTest with a coverage-guided fuzzer like syzkaller.
fuzzers
> Signed-off-by: Ethan Graham <ethangraham@google.com>
> Signed-off-by: Ethan Graham <ethan.w.s.graham@gmail.com>
I believe one of two SoBs is enough.
> Acked-by: Alexander Potapenko <glider@google.com>
...
> --- a/drivers/auxdisplay/Makefile
> +++ b/drivers/auxdisplay/Makefile
> @@ -6,6 +6,9 @@
> obj-$(CONFIG_ARM_CHARLCD) += arm-charlcd.o
> obj-$(CONFIG_CFAG12864B) += cfag12864b.o cfag12864bfb.o
> obj-$(CONFIG_CHARLCD) += charlcd.o
> +ifeq ($(CONFIG_KFUZZTEST),y)
> +CFLAGS_charlcd.o += -include $(src)/tests/charlcd_kfuzz.c
> +endif
> obj-$(CONFIG_HD44780_COMMON) += hd44780_common.o
> obj-$(CONFIG_HD44780) += hd44780.o
> obj-$(CONFIG_HT16K33) += ht16k33.o
Yes, this level of intrusion is fine to me.
...
> +++ b/drivers/auxdisplay/tests/charlcd_kfuzz.c
So, this will require it to be expanded each time we want to add
coverage. Can this be actually generated based on the C
(preprocessed?) level of prototypes listed? Ideally I would like to
see only some small meta-data and then the fuzzer should create the
object based on the profile of the module.
Input like:
bool parse_xy(const char *s $nonnull$, unsigned long *x $nonnull$,
unsigned long *y $nonnull$)
Or even with the expected ranges, and then you can generate a code
that tests the behaviour inside given ranges and outside, including
invalid input, etc.
But okay, the below seems not too big enough.
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * charlcd KFuzzTest target
> + *
> + * Copyright 2025 Google LLC
> + */
> +#include <linux/kfuzztest.h>
> +
> +struct parse_xy_arg {
> + const char *s;
> +};
> +static bool parse_xy(const char *s, unsigned long *x, unsigned long *y);
Is it still needed?
I mean, can we make sure that include in this case works as tail one
and not head, because otherwise we would need to add the respective
includes, i.e. for bool type here, which is missing. Also I *hope&
that kfuzztest.h is NOT Yet Another Include EVERYTHING type of
headers. Otherwise it breaks the whole idea behind modularity of the
headers.
> +FUZZ_TEST(test_parse_xy, struct parse_xy_arg)
> +{
> + unsigned long x, y;
> +
> + KFUZZTEST_EXPECT_NOT_NULL(parse_xy_arg, s);
> + KFUZZTEST_ANNOTATE_STRING(parse_xy_arg, s);
> + parse_xy(arg->s, &x, &y);
> +}
--
With Best Regards,
Andy Shevchenko
On Thu, 4 Dec 2025 at 16:26, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: [..] > > Signed-off-by: Ethan Graham <ethangraham@google.com> > > Signed-off-by: Ethan Graham <ethan.w.s.graham@gmail.com> > > I believe one of two SoBs is enough. Per my interpretation of https://docs.kernel.org/process/submitting-patches.html#developer-s-certificate-of-origin-1-1 it's required where the affiliation/identity of the author has changed; it's as if another developer picked up the series and continues improving it.
On Thu, Dec 4, 2025 at 5:33 PM Marco Elver <elver@google.com> wrote: > On Thu, 4 Dec 2025 at 16:26, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: [..] > > > Signed-off-by: Ethan Graham <ethangraham@google.com> > > > Signed-off-by: Ethan Graham <ethan.w.s.graham@gmail.com> > > > > I believe one of two SoBs is enough. > > Per my interpretation of > https://docs.kernel.org/process/submitting-patches.html#developer-s-certificate-of-origin-1-1 > it's required where the affiliation/identity of the author has > changed; it's as if another developer picked up the series and > continues improving it. Since the original address does not exist, the Originally-by: or free text in the commit message / cover letter should be enough. -- With Best Regards, Andy Shevchenko
On Thu, 4 Dec 2025 at 16:34, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Thu, Dec 4, 2025 at 5:33 PM Marco Elver <elver@google.com> wrote: > > On Thu, 4 Dec 2025 at 16:26, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > [..] > > > > > Signed-off-by: Ethan Graham <ethangraham@google.com> > > > > Signed-off-by: Ethan Graham <ethan.w.s.graham@gmail.com> > > > > > > I believe one of two SoBs is enough. > > > > Per my interpretation of > > https://docs.kernel.org/process/submitting-patches.html#developer-s-certificate-of-origin-1-1 > > it's required where the affiliation/identity of the author has > > changed; it's as if another developer picked up the series and > > continues improving it. > > Since the original address does not exist, the Originally-by: or free > text in the commit message / cover letter should be enough. The original copyright still applies, and the SOB captures that.
On Thu, Dec 4, 2025 at 5:36 PM Marco Elver <elver@google.com> wrote: > On Thu, 4 Dec 2025 at 16:34, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Thu, Dec 4, 2025 at 5:33 PM Marco Elver <elver@google.com> wrote: > > > On Thu, 4 Dec 2025 at 16:26, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: [..] > > > > > Signed-off-by: Ethan Graham <ethangraham@google.com> > > > > > Signed-off-by: Ethan Graham <ethan.w.s.graham@gmail.com> > > > > > > > > I believe one of two SoBs is enough. > > > > > > Per my interpretation of > > > https://docs.kernel.org/process/submitting-patches.html#developer-s-certificate-of-origin-1-1 > > > it's required where the affiliation/identity of the author has > > > changed; it's as if another developer picked up the series and > > > continues improving it. > > > > Since the original address does not exist, the Originally-by: or free > > text in the commit message / cover letter should be enough. > > The original copyright still applies, and the SOB captures that. The problem is that you put a non-existing person there. Make sure emails are not bouncing and I will not object (however, I just saw Greg's reply). -- With Best Regards, Andy Shevchenko
On Thu, Dec 4, 2025 at 6:10 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Thu, Dec 4, 2025 at 5:36 PM Marco Elver <elver@google.com> wrote: > > On Thu, 4 Dec 2025 at 16:34, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > > On Thu, Dec 4, 2025 at 5:33 PM Marco Elver <elver@google.com> wrote: > > > > On Thu, 4 Dec 2025 at 16:26, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > [..] > > > > > > > Signed-off-by: Ethan Graham <ethangraham@google.com> > > > > > > Signed-off-by: Ethan Graham <ethan.w.s.graham@gmail.com> > > > > > > > > > > I believe one of two SoBs is enough. > > > > > > > > Per my interpretation of > > > > https://docs.kernel.org/process/submitting-patches.html#developer-s-certificate-of-origin-1-1 > > > > it's required where the affiliation/identity of the author has > > > > changed; it's as if another developer picked up the series and > > > > continues improving it. > > > > > > Since the original address does not exist, the Originally-by: or free > > > text in the commit message / cover letter should be enough. > > > > The original copyright still applies, and the SOB captures that. > > The problem is that you put a non-existing person there. Make sure > emails are not bouncing and I will not object (however, I just saw > Greg's reply). Understood. I'll stick to the single SoB in the next version as Greg suggested. This address is permanent, so there won't be any bouncing issues.
On Thu, 4 Dec 2025 at 16:35, Marco Elver <elver@google.com> wrote: > On Thu, 4 Dec 2025 at 16:34, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > > > On Thu, Dec 4, 2025 at 5:33 PM Marco Elver <elver@google.com> wrote: > > > On Thu, 4 Dec 2025 at 16:26, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > > > [..] > > > > > > > Signed-off-by: Ethan Graham <ethangraham@google.com> > > > > > Signed-off-by: Ethan Graham <ethan.w.s.graham@gmail.com> > > > > > > > > I believe one of two SoBs is enough. > > > > > > Per my interpretation of > > > https://docs.kernel.org/process/submitting-patches.html#developer-s-certificate-of-origin-1-1 > > > it's required where the affiliation/identity of the author has > > > changed; it's as if another developer picked up the series and > > > continues improving it. > > > > Since the original address does not exist, the Originally-by: or free > > text in the commit message / cover letter should be enough. > > The original copyright still applies, and the SOB captures that. +Cc Greg - who might be able to shed a light on tricky cases like this. tldr; Ethan left Google, but continues to develop series in personal capacity. Question about double-SOB requirement above. Thanks, -- Marco
On Thu, Dec 04, 2025 at 04:42:37PM +0100, Marco Elver wrote: > On Thu, 4 Dec 2025 at 16:35, Marco Elver <elver@google.com> wrote: > > On Thu, 4 Dec 2025 at 16:34, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > > > > > On Thu, Dec 4, 2025 at 5:33 PM Marco Elver <elver@google.com> wrote: > > > > On Thu, 4 Dec 2025 at 16:26, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > > > > > [..] > > > > > > > > > Signed-off-by: Ethan Graham <ethangraham@google.com> > > > > > > Signed-off-by: Ethan Graham <ethan.w.s.graham@gmail.com> > > > > > > > > > > I believe one of two SoBs is enough. > > > > > > > > Per my interpretation of > > > > https://docs.kernel.org/process/submitting-patches.html#developer-s-certificate-of-origin-1-1 > > > > it's required where the affiliation/identity of the author has > > > > changed; it's as if another developer picked up the series and > > > > continues improving it. > > > > > > Since the original address does not exist, the Originally-by: or free > > > text in the commit message / cover letter should be enough. > > > > The original copyright still applies, and the SOB captures that. > > +Cc Greg - who might be able to shed a light on tricky cases like this. > > tldr; Ethan left Google, but continues to develop series in personal > capacity. Question about double-SOB requirement above. It's the same natural person, so only 1 is needed. thanks, greg k-h
On Thu, Dec 4, 2025 at 5:26 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > On Thu, Dec 4, 2025 at 4:13 PM Ethan Graham <ethan.w.s.graham@gmail.com> wrote: > > From: Ethan Graham <ethangraham@google.com> OK, this bounces. Please update the series to make sure you have no dead addresses in it. -- With Best Regards, Andy Shevchenko
© 2016 - 2025 Red Hat, Inc.