On Tue Apr 14, 2026 at 12:20 AM CEST, Andrey Konovalov wrote: > On Mon, Apr 13, 2026 at 8:29 PM Alexis Lothoré (eBPF Foundation) > <[email protected]> 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. >> >> This version implements two faulty programs triggering either a >> user-after-free, or an out-of-bounds memory usage. The bugs are >> triggered thanks to some dedicated kfuncs in bpf_testmod.c, but two >> different techniques are used, as some cases can be quite hard to >> trigger in a pure "black box" approach: >> - for reads, we can make the used kfuncs return some faulty pointers >> that ebpf programs will manipulate, they will generate legitimate >> kasan reports as a consequence >> - applying the same trick for faulty writes is harder, as ebpf programs >> can't write kernel data freely. So ebpf programs can call another >> specific testing kfunc that will alter the shadow memory matching the >> passed memory (eg: a map). When the program will try to write to the >> corresponding memory, it will trigger a report as well. >> >> Signed-off-by: Alexis Lothoré (eBPF Foundation) <[email protected]> >> --- >> The way of bringing kasan_poison into bpf_testmod is definitely not >> ideal. But I would like to validate the testing approach (triggering >> real faulty accesses, which is hard on some cases, VS manually poisoning >> BPF-manipulated memory) before eventually making clean bridges between >> KASAN APIs and bpf_testmod.c, if the latter approach is the valid one. > > Would it make sense to put these tests into KASAN KUnit tests in > mm/kasan/kasan_test_c.c? I assume there is a kernel API to JIT BPF > programs from the kernel itself?
Possibly indeed, but I think one important use case will be the possibility to run those tests in BPF CI ([1]), and this depends on those tests being integrated in the test_progs framework (tools/testing/selftests/bpf) [1] https://github.com/kernel-patches/bpf/pulls > There, you can just call kasan_poison(), some tests already do this. > And you can also extend the KASAN KUnit test framework to find out > whether the bad access is a read or write, if you want to check this. Alexis -- Alexis Lothoré, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
