[PATCH] kunit: fix use-after-free in debugfs when using kunit.filter

0 views
Skip to first unread message

Florian Schmaus

unread,
May 7, 2026, 4:49:13 AMMay 7
to Brendan Higgins, David Gow, Rae Moar, linux-k...@vger.kernel.org, kuni...@googlegroups.com, linux-...@vger.kernel.org, Florian Schmaus
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...@codasip.com>
---
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);

--
2.53.0

Martin Kaiser

unread,
May 11, 2026, 9:29:01 AM (14 days ago) May 11
to Florian Schmaus, Brendan Higgins, David Gow, Rae Moar, linux-k...@vger.kernel.org, kuni...@googlegroups.com, linux-...@vger.kernel.org
Thus wrote Florian Schmaus (florian...@codasip.com):

> 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...@codasip.com>

Reviewed-by: Martin Kaiser <mar...@kaiser.cx>

David Gow

unread,
May 14, 2026, 9:29:56 AM (11 days ago) May 14
to Florian Schmaus, Brendan Higgins, Rae Moar, linux-k...@vger.kernel.org, kuni...@googlegroups.com, linux-...@vger.kernel.org
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...@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 <da...@davidgow.net>


Cheers,
-- David
Reply all
Reply to author
Forward
0 new messages