Re: [PATCH RFC bpf-next 8/8] selftests/bpf: add tests to validate KASAN on JIT programs

[sashiko-bot@kernel.org]

Sashiko AI review found 4 potential issue(s):
- [High] Missing `KF_RET_NULL` flag on UAF kfuncs allows unhandled NULL pointer dereference in kernel.
- [High] Test fails on default single-shot KASAN or panics the kernel if `panic_on_warn` is enabled.
- [Medium] `klog_buffer` is not null-terminated after `klogctl()`, leading to out-of-bounds reads and stale data matching.
- [Medium] Global kernel syslog ring buffer is permanently deleted by the test.
--

commit 9698a3d81fe93ffca4f2e04fcf453d8b53dfd91c
Author: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>

selftests/bpf: add tests to validate KASAN on JIT programs

This commit adds a basic KASAN test runner that loads and runs BPF programs
to trigger memory management bugs. The test captures kernel logs and ensures
the expected KASAN splat is emitted.

> diff --git a/tools/testing/selftests/bpf/prog_tests/kasan.c b/tools/testing/selftests/bpf/prog_tests/kasan.c
> new file mode 100644
> index 0000000000000..fd628aaa80057
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/kasan.c
[ ... ]
> +static int read_kernel_logs(char *buf, size_t max_len)
> +{
> +	return klogctl(SYSLOG_ACTION_READ_ALL, buf, max_len);
> +}

Since klogctl() returns the number of bytes read but doesn't null-terminate
the buffer, and klog_buffer is statically allocated and reused, could
strstr() in kernel_logs_have_matching_kasan_report() read past the end of
the buffer or match stale logs from previous runs?

> +
> +static int clear_kernel_logs(void)
> +{
> +	return klogctl(SYSLOG_ACTION_CLEAR, NULL, 0);
> +}

Does clearing the global syslog ring buffer with SYSLOG_ACTION_CLEAR break
concurrent tests?

This destroys all dmesg logs generated by other tests in the parallel BPF
selftest framework.

Should the test read /dev/kmsg incrementally instead?

[ ... ]
> +static void run_test_with_type(struct kasan *skel, struct test_spec *test,
> +			       bool is_write)
> +{
> +	run_test_with_type_and_size(skel, test, is_write, 1);
> +	run_test_with_type_and_size(skel, test, is_write, 2);
> +	run_test_with_type_and_size(skel, test, is_write, 4);
> +	run_test_with_type_and_size(skel, test, is_write, 8);
> +}

KASAN operates in single-shot mode by default. After the first subtest
triggers a report, will subsequent reports be suppressed, causing the
remaining subtests to fail?

Also, since BPF CI runs with panic_on_warn=1, will the first KASAN splat
invoke check_panic_on_warn() and immediately panic the CI runner?

> diff --git a/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c b/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
> index d876314a4d67e..01554bcbbbb0a 100644
> --- a/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
> +++ b/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
[ ... ]
> +static void *kasan_uaf(void)
> +{
> +	void *p = kmalloc(64, GFP_ATOMIC);
> +
> +	if (!p)
> +		return NULL;
> +	memset(p, 0xAA, 64);
> +	kfree(p);
> +
> +	return p;
> +}
[ ... ]
> +BTF_ID_FLAGS(func, bpf_kfunc_kasan_uaf_1)
> +BTF_ID_FLAGS(func, bpf_kfunc_kasan_uaf_2)
> +BTF_ID_FLAGS(func, bpf_kfunc_kasan_uaf_4)
> +BTF_ID_FLAGS(func, bpf_kfunc_kasan_uaf_8)

Since kasan_uaf() can return NULL if kmalloc() fails under memory pressure,
should these kfuncs be registered with the KF_RET_NULL flag?

Without it, the BPF verifier won't enforce NULL checks in the BPF programs,
which could lead to unhandled NULL pointer dereferences in kernel space.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260413-kasan-v1-0-1a5831230821@bootlin.com?part=8