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

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

On Thu Sep 3, 2026 at 3:51 PM CEST, Alexis Lothoré (eBPF Foundation) wrote:
> Hello,
> this is v9 of the series aiming to bring basic support for KASAN checks
> to BPF JITed programs. Among a few minor optimizations, this revision
> fixes some wrong kasan instrumentation on some unwanted stack access
> (stack access ending up being instrumented AND targeting the wrong stack
> offset). To mitigate this risk further, this revision introduces a
> systematic KASAN check skip when (addr_reg == BPF_REG_FP || addr_reg ==
> BPF_REG_PARAMS) in emit_kasan_check. This secondary check (on top of the
> non_stack_access flag), should hopefully prevent the issues raised in
> v8. I've also reworked the emit_st refactoring to realign it with
> BPF_STX management in the x86 JIT compiler, as the "arguments on stack"
> feature made me realize that it could be kept more symmetric with
> BPF_STX; so I've dropped Ihor's Acked-by on this.
>
> Original cover letter:
>
> "Traditional" KASAN allows to spot memory management mistakes by
> reserving a fraction of memory as "shadow memory" that will map to the
> rest of the memory and allow its monitoring. Each memory-accessing
> instruction is then instrumented at build time to call some ASAN check
> function, that will analyze the corresponding bits in shadow memory, and
> if it detects the access as invalid, trigger a detailed report. The goal
> of this series is to replicate this mechanism for BPF programs when they
> are being JITed into native instructions: that's then the JIT compiler
> that is in charge of inserting calls to the corresponding kasan checks,
> when a program is being loaded into the kernel. This task involves:
> - identifying at program load time the instructions performing memory
>   accesses
> - identifying those accesses properties (size ? read or write ?) to
>   define the relevant kasan check function to call
> - just before the identified instructions:
>   - perform the basic context saving (ie: saving registers)
>   - inserting a call to the relevant kasan check function
>   - restore context
> - whenever the instrumented program executes, if it performs an invalid
>   access, it triggers a kasan report identical to those instrumented on
>   kernel side at build time.
>
> The series comes with new selftests programs that generate a wide
> variety of kasan reports: those need the kernel to be running with
> kasan_multi_shot enabled.
>
> As discussed in [1], this series is based on some choices and
> assumptions:
> - it focuses on x86_64 for now, and so only on KASAN_GENERIC
> - not all memory accessing BPF instructions are being instrumented:
>   - it discards instructions accessing BPF program stack (already
>     monitored by page guards)
>   - it discards possibly faulting instructions, like BPF_PROBE_MEM or
>     BPF_PROBE_ATOMIC insns
>

For the series:
Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>

If there are remaining issues, we can fix forward, but I think we should try and
land this for now.

> [...]