Re: [PATCH bpf-next v7 0/9] bpf: add support for KASAN checks in JITed programs

[Ihor Solodrai <ihor.solodrai@linux.dev>]

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
>