On 2026-08-27 12:01 a.m., Alexis Lothoré wrote:
Hi Ihor,
On Wed Aug 26, 2026 at 11:00 PM CEST, Ihor Solodrai wrote:
On 2026-08-23 3:53 p.m., Kumar Kartikeya Dwivedi wrote:
On Sat Aug 22, 2026 at 12:39 AM CEST, Alexis Lothoré (eBPF Foundation) wrote:
Hello,
this is v7 of the series aiming to bring basic support for KASAN checks
to BPF JITed programs. This new revision just makes the series rebased
on top of current bpf-next_base.
Please note that with the recent kernel splat detector introduced in
kernel-patches/vmtest through commit 8109e5928cd0 ("ci: own the kernel
splat matching (#509)"), CI runs on this series will fail with the
following error.
Error: kernel splat detected: [ 100.689549] BUG: KASAN: \
slab-use-after-free in \
bpf_prog_eba69524d1d949b1_st_not_on_stack+0x12f/0x17a \
which is pretty normal, as the new selftests introduced by this series
are expected to trigger KASAN splats (the test_progs part will pass,
only the kernel_splats part will trigger errors). The right fix may be
to just put a list of regex matching all the kasan subtests progs in the
relevant SPLAT_ALLOWLIST file; something like:
BUG: KASAN: slab-(out-of-bounds|use-after-free) in
bpf_prog_([a-f0-9]){16}_(st|ld)(x)?(_not)?_on_stack\+
BUG: KASAN: slab-(out-of-bounds|use-after-free) in
bpf_prog_([a-f0-9]){16}_simple_atomic(_fetch)?(_not)_on_stack\+
BUG: KASAN: slab-(out-of-bounds|use-after-free) in
bpf_prog_([a-f0-9]){16}_ldx_patched(_not)?_on_stack\+
BUG: KASAN: slab-(out-of-bounds|use-after-free) in
bpf_prog_([a-f0-9]){16}_verifier_paths_stack_and_non_stack\+
BUG: KASAN: slab-(out-of-bounds|use-after-free) in
bpf_prog_([a-f0-9]){16}_ldx_oob\+
BUG: KASAN: slab-(out-of-bounds|use-after-free) in
bpf_prog_([a-f0-9]){16}_st_blinded\+
BUG: KASAN: slab-(out-of-bounds|use-after-free) in
bpf_prog_([a-f0-9]){16}_(load_acquire|store_release)(_not)?_on_stack\+
I can take care of opening the relevant PR in kernel-patches/vmtest with
this if it ends up being the correct solution, but it will make sense to
do so only once the selftests list is validated (but before merging the
series).
We need to resolve this before landing the set. To me it looks inevitable, esp.
if we exercise the support and produce such warnings. That said I'll let Ihor
respond and provide guidance for this. We should probably land the vmtest PR
before v8 is posted, so that v8 can go through CI and be processed without
failures.
This is a tricky one.
IIUC the suggested allowlist regex will also mask the real splats, which
the whole KASAN-in-JIT project was supposed to catch.
Not really: the proposed list of regex above just discards the splat
emitted by the progs used by the tests related to the KASAN feature (so
any prog in tools/testing/selftests/bpf/prog/{kasan.c,kasan_harden.c},
which anyway generate "fake" KASAN splat for most of them, since we are
manually poisoning some valid memory to trigger the splats. Any other
program that generate a splat will be caught by the splat detector.
Ah, I see. The regexes have BPF prog names in them.
Then yes, the SPLAT_ALLOWLIST is the right fix.
Thanks for explaining.
I think a good way to resolve this is to teach the kasan splat
detection script about these tests, and drop/skip them from the dmesg
log it inspects. For example, match begin / end of the test set.
Might require special log anchors printed by the test itself, but
you get the idea.
Alexis, do you mind trying this?
If despite the comment above, teaching check-kernel-splat.sh how to
ignore the kasan selftests specific splats remains a better solution,
sure, I can work on this.
No need. Let's do the SPLAT_ALLOWLIST, I'll take a look at your CI PR
shortly.
Thanks,
Alexis
