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.
>
> 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.
Thanks,
Alexis
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
