From: David Gow <david@davidgow.net>
To: Florian Schmaus <florian.schmaus@codasip.com>,
Brendan Higgins <brendan.higgins@linux.dev>,
Rae Moar <raemoar63@gmail.com>
Cc: linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kunit: fix use-after-free in debugfs when using kunit.filter
Date: Thu, 14 May 2026 21:29:47 +0800 [thread overview]
Message-ID: <7f673258-e608-4d67-b092-c9dbb533d2f4@davidgow.net> (raw)
In-Reply-To: <20260507084854.233984-1-florian.schmaus@codasip.com>
Le 07/05/2026 à 4:48 PM, 'Florian Schmaus' via KUnit Development a écrit :
> When the kernel is booted with a kunit filter (e.g.,
> kunit.filter="speed!=slow"), the kunit executor dynamically allocates
> copies of the filtered test suites using kmalloc/kmemdup.
>
> During the initial boot execution, kunit_debugfs_create_suite() creates
> debugfs files (such as /sys/kernel/debug/kunit/<suite>/run) and
> permanently stores a pointer to the dynamically allocated suite in the
> inode's i_private field.
>
> Previously, the executor freed this dynamically allocated suite_set
> immediately after executing the boot-time tests. Because the debugfs
> nodes were not destroyed, any subsequent interaction with the debugfs
> `run` file from userspace triggered a use-after-free (UAF). On systems
> with architectural capabilities, like CHERI RISC-V, this resulted in
> an immediate fatal hardware exception due to the invalidation of the
> capability tags on the reclaimed memory. On other architectures, it
> resulted in silent memory corruption.
>
> Fix this UAF by properly coupling the lifetime of the filtered suite
> memory allocation to the lifetime of the kunit subsystem and its
> associated VFS nodes. Ownership of the boot-time suite_set is now
> transferred to a global tracker ('kunit_boot_suites'), and the memory
> is cleanly released in kunit_exit() during module teardown.
>
> Signed-off-by: Florian Schmaus <florian.schmaus@codasip.com>
> ---
Nice catch. Alas, I don't have any CHERI-style setups at the moment to
actually test it out, but it looks right to me, and doesn't break
anything.
It might be useful to add a Fixes tag to this if you do a future
version: I think that the culprit commit is probably the original
debugfs one:
Fixes: e2219db280e3 ("kunit: add debugfs /sys/kernel/debug/kunit/<suite>/results display")
Reviewed-by: David Gow <david@davidgow.net>
Cheers,
-- David
> include/kunit/test.h | 1 +
> lib/kunit/executor.c | 19 ++++++++++++++++---
> lib/kunit/test.c | 1 +
> 3 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/include/kunit/test.h b/include/kunit/test.h
> index 9cd1594ab697..ce0573e196ce 100644
> --- a/include/kunit/test.h
> +++ b/include/kunit/test.h
> @@ -613,6 +613,7 @@ unsigned long kunit_vm_mmap(struct kunit *test, struct file *file,
> unsigned long offset);
>
> void kunit_cleanup(struct kunit *test);
> +void kunit_free_boot_suites(void);
>
> void __printf(2, 3) kunit_log_append(struct string_stream *log, const char *fmt, ...);
>
> diff --git a/lib/kunit/executor.c b/lib/kunit/executor.c
> index 1fef217de11d..b0f8a41d61d3 100644
> --- a/lib/kunit/executor.c
> +++ b/lib/kunit/executor.c
> @@ -15,6 +15,16 @@ extern struct kunit_suite * const __kunit_suites_end[];
> extern struct kunit_suite * const __kunit_init_suites_start[];
> extern struct kunit_suite * const __kunit_init_suites_end[];
>
> +static struct kunit_suite_set kunit_boot_suites;
> +
> +void kunit_free_boot_suites(void)
> +{
> + if (kunit_boot_suites.start) {
> + kunit_free_suite_set(kunit_boot_suites);
> + kunit_boot_suites = (struct kunit_suite_set){ NULL, NULL };
> + }
> +}
> +
> static char *action_param;
>
> module_param_named(action, action_param, charp, 0400);
> @@ -411,9 +421,12 @@ int kunit_run_all_tests(void)
> pr_err("kunit executor: unknown action '%s'\n", action_param);
>
> free_out:
> - if (filter_glob_param || filter_param)
> - kunit_free_suite_set(suite_set);
> - else if (init_num_suites > 0)
> + if (filter_glob_param || filter_param) {
> + if (err)
> + kunit_free_suite_set(suite_set);
> + else
> + kunit_boot_suites = suite_set;
> + } else if (init_num_suites > 0)
> /* Don't use kunit_free_suite_set because suites aren't individually allocated */
> kfree(suite_set.start);
>
> diff --git a/lib/kunit/test.c b/lib/kunit/test.c
> index 41e1c89799b6..99773e000e1b 100644
> --- a/lib/kunit/test.c
> +++ b/lib/kunit/test.c
> @@ -1075,6 +1075,7 @@ static void __exit kunit_exit(void)
> kunit_bus_shutdown();
>
> kunit_debugfs_cleanup();
> + kunit_free_boot_suites();
> }
> module_exit(kunit_exit);
>
prev parent reply other threads:[~2026-05-14 13:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-07 8:48 [PATCH] kunit: fix use-after-free in debugfs when using kunit.filter Florian Schmaus
2026-05-11 13:28 ` Martin Kaiser
2026-05-14 13:29 ` David Gow [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7f673258-e608-4d67-b092-c9dbb533d2f4@davidgow.net \
--to=david@davidgow.net \
--cc=brendan.higgins@linux.dev \
--cc=florian.schmaus@codasip.com \
--cc=kunit-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=raemoar63@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox