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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Uninitialized stack memory is passed to the kernel via bpf_prog_test_run_opts, causing potential information leaks and triggering MSAN warnings.
- [Medium] The KASAN report parser is susceptible to spurious failures due to kernel log interleaving.
--

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

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

This patch adds a basic KASAN test runner that loads and test-runs BPF programs
designed to trigger memory management bugs. The test captures kernel logs and
ensures the expected KASAN splat is emitted by searching for the corresponding
first lines in the report.

> 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..ff070c39eaac1
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/kasan.c

[ ... ]

> +static int check_kasan_report_in_kernel_logs(char *buf, struct test_ctx *ctx,
> +					     bool is_write, int size)
> +{
> +	char *access_desc_start, *access_desc_end, *tmp;

[ ... ]

> +	/* Find next line */
> +	access_desc_start = strchr(kasan_report_start, '\n');
> +	if (!access_desc_start)
> +		return 1;
> +	access_desc_start++;
> +
> +	access_desc_end = strchr(access_desc_start, '\n');
> +	if (!access_desc_end)
> +		return 1;
> +
> +	nsize = snprintf(access_log, READ_CHUNK_SIZE, KASAN_PATTERN_REPORT,
> +			 is_write ? "Write" : "Read", size);
> +
> +	tmp = memmem(access_desc_start, access_desc_end - access_desc_start,
> +		     access_log, nsize);

[Severity: Medium]
Could this fail if other kernel components interleave log messages between the
KASAN header and the access description?

The parser assumes the exact next newline-delimited block contains the access
description. However, the report_lock used by KASAN internally only serializes
KASAN reports with each other, not with general printk output from other CPUs
or contexts. If another component prints a message precisely between the KASAN
header and the access description, the search bounds might be restricted to an
unrelated interleaved log line, causing memmem() to fail and making the test
flaky.

> +
> +	if (!tmp)
> +		return 1;
> +
> +	return 0;
> +}

[ ... ]

> +static void exec_subtest(struct test_ctx *ctx, struct test_spec *test,
> +			 int access_size, bool on_stack)
> +{
> +	LIBBPF_OPTS(bpf_test_run_opts, topts);
> +	struct bpf_prog_info info;
> +	uint8_t buf[ETH_HLEN];

[Severity: Medium]
Should buf be initialized before being passed to bpf_prog_test_run_opts()?

Uninitialized stack memory from the test executable is assigned to
topts.data_in and leaked into the kernel space via copy_from_user():

	topts.data_in = buf;
	ret = bpf_prog_test_run_opts(bpf_program__fd(ctx->prog), &topts);

This uninitialized access can trigger userspace dynamic analysis tools such as
MemorySanitizer (MSAN) when running the BPF selftests, causing spurious test
suite failures.

> +	int ret, prog_fd;
> +	__u32 info_len;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701-kasan-v3-0-bd09bb942d86@bootlin.com?part=10