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

["Alexis Lothoré" <alexis.lothore@bootlin.com>]

On Wed Jul 1, 2026 at 12:34 PM CEST, sashiko-bot wrote:
> 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.

Indeed. I'll update this to search _in the rest of the logs_ rather than
_on the very next line_, assuming that each subtest generates at most a single
report.

Alexis


-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com