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

["Kumar Kartikeya Dwivedi" <memxor@gmail.com>]

On Sat Aug 22, 2026 at 12:39 AM CEST, 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).
> Most of those tests are able to trigger kasan reports by altering the
> shadow memory (triggering faulty accesses is otherwise complex, because
> of the verifier). A few tests trigger actual faulty accesses (eg
> out-of-bound accesses)
>
> A few of those tests depends on cpuv4 (load_acquire and store_release).
>
>   # ./test_progs -a kasan
>   #171/1   kasan/st_1_not_on_stack:OK
>   #171/2   kasan/st_1_on_stack:OK
>   #171/3   kasan/st_2_not_on_stack:OK
>   #171/4   kasan/st_2_on_stack:OK
>   #171/5   kasan/st_4_not_on_stack:OK
>   #171/6   kasan/st_4_on_stack:OK
>   #171/7   kasan/st_8_not_on_stack:OK
>   #171/8   kasan/st_8_on_stack:OK
>   #171/9   kasan/stx_1_not_on_stack:OK
>   #171/10  kasan/stx_1_on_stack:OK
>   #171/11  kasan/stx_2_not_on_stack:OK
>   #171/12  kasan/stx_2_on_stack:OK
>   #171/13  kasan/stx_4_not_on_stack:OK
>   #171/14  kasan/stx_4_on_stack:OK
>   #171/15  kasan/stx_8_not_on_stack:OK
>   #171/16  kasan/stx_8_on_stack:OK
>   #171/17  kasan/ldx_1_not_on_stack:OK
>   #171/18  kasan/ldx_1_on_stack:OK
>   #171/19  kasan/ldx_2_not_on_stack:OK
>   #171/20  kasan/ldx_2_on_stack:OK
>   #171/21  kasan/ldx_4_not_on_stack:OK
>   #171/22  kasan/ldx_4_on_stack:OK
>   #171/23  kasan/ldx_8_not_on_stack:OK
>   #171/24  kasan/ldx_8_on_stack:OK
>   #171/25  kasan/simple_atomic_4_not_on_stack:OK
>   #171/26  kasan/simple_atomic_4_on_stack:OK
>   #171/27  kasan/simple_atomic_8_not_on_stack:OK
>   #171/28  kasan/simple_atomic_8_on_stack:OK
>   #171/29  kasan/simple_atomic_fetch:OK
>   #171/30  kasan/simple_atomic_fetch:OK
>   #171/31  kasan/load_acquire_1_not_on_stack:SKIP
>   #171/32  kasan/load_acquire_1_on_stack:SKIP
>   #171/33  kasan/load_acquire_2_not_on_stack:SKIP
>   #171/34  kasan/load_acquire_2_on_stack:SKIP
>   #171/35  kasan/load_acquire_4_not_on_stack:SKIP
>   #171/36  kasan/load_acquire_4_on_stack:SKIP
>   #171/37  kasan/load_acquire_8_not_on_stack:SKIP
>   #171/38  kasan/load_acquire_8_on_stack:SKIP
>   #171/39  kasan/store_release_1_not_on_stack:SKIP
>   #171/40  kasan/store_release_1_on_stack:SKIP
>   #171/41  kasan/store_release_2_not_on_stack:SKIP
>   #171/42  kasan/store_release_2_on_stack:SKIP
>   #171/43  kasan/store_release_4_not_on_stack:SKIP
>   #171/44  kasan/store_release_4_on_stack:SKIP
>   #171/45  kasan/store_release_8_not_on_stack:SKIP
>   #171/46  kasan/store_release_8_on_stack:SKIP
>   #171/47  kasan/ldx_patched:OK
>   #171/48  kasan/ldx_patched:OK
>   #171/49  kasan/verifier_paths_stack_and_non_stack:OK
>   #171/50  kasan/ldx_oob_1_not_on_stack:OK
>   #171/51  kasan/ldx_oob_2_not_on_stack:OK
>   #171/52  kasan/ldx_oob_4_not_on_stack:OK
>   #171/53  kasan/ldx_oob_8_not_on_stack:OK
>   #171/54  kasan/st_blinded:OK
>   #171     kasan:OK (SKIP: 16/54)
>   Summary: 1/38 PASSED, 16 SKIPPED, 0 FAILED
>
> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
> ---

1. Should this test be made serial to make sure bpf_jit_harden sysctl change
doesn't affect other tests?
2. Clang currently collapses the intended ST/STX distinction for *_on_stack
tests: default/v3 emits STX for both pairs, cpuv4 emits ST for both, and the
default st_blinded object is already STX and therefore is not blinded. Please
check and assert that xlated insns are correct in the test itself if possible.
It might be necessary to use asm volatile assembly blocks in case you cannot
work around the compiler in C.