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

[Ihor Solodrai]

On 7/9/26 3:01 AM, Alexis Lothoré (eBPF Foundation) wrote:
> Add a basic KASAN test runner that loads and test-run programs that can
> trigger memory management bugs. The test captures kernel logs and ensure
> that the expected KASAN splat is emitted by searching for the
> corresponding first lines in the report, hence validated that the needed
> instrumentation has been inserted by the JIT compiler before the
> relevant memory accesses. To allow each test to trigger the expected
> report, the kernel must run with the kasan_multi_shot configuration.
> 
> The runner covers different cases and settings: in the nominal case, it
> validates kasan reports on basic instructions (on all supported accesses
> sizes) but also when report _should not_ be emitted (eg: for accesses on
> program stack). The runner also comes with a few specialized tests that
> are then not executed for all sizes/locations:
> - specific atomic ops
> - test for instructions involving different verifier states, with some
>   states flagging memory as stack, and other states as non-stack memory
> - tests that validate the stack marking shifting when a patch is emitted
>   by the verifier (zext/rnd_hi32, constant blindind)
> 
> A few of those tests depends on cpuv4 (load_acquire and store_release).
> 
>   # ./test_progs -a kasan
>   #165/1   kasan/st_1_not_on_stack:OK
>   #165/2   kasan/st_1_on_stack:OK
>   #165/3   kasan/st_2_not_on_stack:OK
>   #165/4   kasan/st_2_on_stack:OK
>   #165/5   kasan/st_4_not_on_stack:OK
>   #165/6   kasan/st_4_on_stack:OK
>   #165/7   kasan/st_8_not_on_stack:OK
>   #165/8   kasan/st_8_on_stack:OK
>   #165/9   kasan/stx_1_not_on_stack:OK
>   #165/10  kasan/stx_1_on_stack:OK
>   #165/11  kasan/stx_2_not_on_stack:OK
>   #165/12  kasan/stx_2_on_stack:OK
>   #165/13  kasan/stx_4_not_on_stack:OK
>   #165/14  kasan/stx_4_on_stack:OK
>   #165/15  kasan/stx_8_not_on_stack:OK
>   #165/16  kasan/stx_8_on_stack:OK
>   #165/17  kasan/ldx_1_not_on_stack:OK
>   #165/18  kasan/ldx_1_on_stack:OK
>   #165/19  kasan/ldx_2_not_on_stack:OK
>   #165/20  kasan/ldx_2_on_stack:OK
>   #165/21  kasan/ldx_4_not_on_stack:OK
>   #165/22  kasan/ldx_4_on_stack:OK
>   #165/23  kasan/ldx_8_not_on_stack:OK
>   #165/24  kasan/ldx_8_on_stack:OK
>   #165/25  kasan/simple_atomic_4_not_on_stack:OK
>   #165/26  kasan/simple_atomic_4_on_stack:OK
>   #165/27  kasan/simple_atomic_8_not_on_stack:OK
>   #165/28  kasan/simple_atomic_8_on_stack:OK
>   #165/29  kasan/load_acquire_1_not_on_stack:SKIP
>   #165/30  kasan/load_acquire_1_on_stack:SKIP
>   #165/31  kasan/load_acquire_2_not_on_stack:SKIP
>   #165/32  kasan/load_acquire_2_on_stack:SKIP
>   #165/33  kasan/load_acquire_4_not_on_stack:SKIP
>   #165/34  kasan/load_acquire_4_on_stack:SKIP
>   #165/35  kasan/load_acquire_8_not_on_stack:SKIP
>   #165/36  kasan/load_acquire_8_on_stack:SKIP
>   #165/37  kasan/store_release_1_not_on_stack:SKIP
>   #165/38  kasan/store_release_1_on_stack:SKIP
>   #165/39  kasan/store_release_2_not_on_stack:SKIP
>   #165/40  kasan/store_release_2_on_stack:SKIP
>   #165/41  kasan/store_release_4_not_on_stack:SKIP
>   #165/42  kasan/store_release_4_on_stack:SKIP
>   #165/43  kasan/store_release_8_not_on_stack:SKIP
>   #165/44  kasan/store_release_8_on_stack:SKIP
>   #165/45  kasan/ldx_patched:OK
>   #165/46  kasan/ldx_patched_on_stack:OK
>   #165/47  kasan/verifier_paths_stack_and_non_stack:OK
>   #165/48  kasan/st_blinded:OK
>   #165     kasan:OK (SKIP: 16/48)
>   Summary: 1/32 PASSED, 16 SKIPPED, 0 FAILED

That's quite comprehensive, good work!

> 
> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@xxxxxxxxxxx>
> ---
> [...]
> +
> +#define MAX_LOG_SIZE		(8 * 1024)
> +#define READ_CHUNK_SIZE		256
> +
> +#define KASAN_PATTERN_SLAB_UAF "BUG: KASAN: slab-use-after-free " \
> +	"in bpf_prog_%02x%02x%02x%02x%02x%02x%02x%02x_%s"
> +#define KASAN_PATTERN_REPORT "%s of size %d at addr"

I don't know how feasible that is, but I think it would be good to
have a test or two for other KASAN errors, like OOB for example.


> [...]
> +
> +SEC("tcx/ingress")
> +int simple_atomic_on_stack(struct __sk_buff *skb)
> +{
> +	struct kasan_write_val val;
> +
> +	bpf_kfunc_kasan_poison(&val, sizeof(struct kasan_write_val));
> +	switch (access_size) {
> +	case 4:
> +		__sync_fetch_and_add(&val.data_4, 4);
> +		break;
> +	case 8:
> +		__sync_fetch_and_add(&val.data_8, 8);

It looks like the BPF_FETCH wouldn't execute this way, because the
result is discarded? And the whole if (is_atomic_fetch) branch in
do_jit() is also not covered?

Maybe it's worth adding a test with __sync_val_compare_and_swap() into
a poisoned map value, or something of the sort?

> +		break;
> +	}
> +	bpf_kfunc_kasan_unpoison(&val, sizeof(struct kasan_write_val));
> +	return 0;
> +}
> +
> +SEC("tcx/ingress")
> +int simple_atomic_not_on_stack(struct __sk_buff *skb)
> +{
> +	struct kasan_write_val *val;
> +	__u32 key = 0;
> +
> +	val = bpf_map_lookup_elem(&test_map, &key);
> +	if (!val)
> +		return 0;
> +
> +	bpf_kfunc_kasan_poison(val, sizeof(struct kasan_write_val));
> +	switch (access_size) {
> +	case 4:
> +		__sync_fetch_and_add(&val->data_4, 4);
> +		break;
> +	case 8:
> +		__sync_fetch_and_add(&val->data_8, 8);
> +		break;
> +	}
> +	bpf_kfunc_kasan_unpoison(val, sizeof(struct kasan_write_val));
> +	return 0;
> +}
> +
> [...]
>