Re: [PATCH bpf-next v3 03/10] bpf: add BPF_JIT_KASAN for KASAN instrumentation of JITed programs

["Alexis Lothoré" <alexis.lothore@bootlin.com>]

On Wed Jul 1, 2026 at 12:12 PM CEST, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] BPF_JIT_KASAN needlessly restricts its availability by unconditionally requiring VMAP_STACK.
> --
>
> commit 23714982e1ca6e827ba19b9f4c74b703b4ad2090
> Author: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
>
> bpf: add BPF_JIT_KASAN for KASAN instrumentation of JITed programs
>
> This commit introduces CONFIG_BPF_JIT_KASAN to enable generic KASAN memory
> access checks for JIT-compiled BPF programs. The JIT compiler emits shadow
> memory checks before memory accesses to detect bugs like use-after-free or
> out-of-bounds at runtime. The feature is gated behind HAVE_EBPF_JIT_KASAN.
>
>> As KASAN instrumentation for eBPF program will depend on the info that
>> can be accessed during each instruction verification, there may be
>> instructions that will be instrumented even if they don't really need to
>> (eg: global subprograms that access caller stack memory passed as
>> argument). To make sure that those additional checks do not trigger any
>> crash, make sure that VMAP_STACK is enabled so that programs stack has
>> shadow memory allocated.
>
> [Severity: Medium]
> Does generic KASAN already map shadow memory for the entire linear mapping?
> If VMAP_STACK is disabled, the kernel stack resides in the linear mapping,
> which should already have shadow memory allocated. Could this justification
> be slightly misunderstanding the default generic KASAN shadow memory coverage?
>
>> diff --git a/kernel/bpf/Kconfig b/kernel/bpf/Kconfig
>> --- a/kernel/bpf/Kconfig
>> +++ b/kernel/bpf/Kconfig
>
> [ ... ]
>
>> @@ -101,4 +105,9 @@ config BPF_LSM
>>  
>>  	  If you are unsure how to answer this question, answer N.
>>  
>> +config BPF_JIT_KASAN
>> +	bool
>> +	depends on HAVE_EBPF_JIT_KASAN
>> +	default y if BPF_JIT && KASAN_GENERIC && KASAN_VMALLOC && VMAP_STACK
>
> [Severity: Medium]
> Is it necessary to unconditionally require VMAP_STACK for BPF_JIT_KASAN?
>
> Following up on the commit message note, since generic KASAN covers the
> linear mapping where non-VMAP stacks reside, this condition might needlessly
> disable a useful security and debugging feature on kernel configurations
> where VMAP_STACK happens to be turned off.

This indeed looks over-constraining. To clarify my original intent (and
make sure that I am not overthinking it):

- the current series does its best to skip instrumentation for memory
  accesses that target the BPF program stack
- there are some cases where it is hard or not even possible to guess if
  the memory access is on stack or not (eg: the verifier fixups that
  generate memory-accessing instructions).
- there are two strategies for those "unknown" accesses: either skip
  KASAN for those, with the risk of missing illegitimate accesses
  because instrumentation has been skipped, or systematically inserting
  KASAN checks, at the risk of slightly over-instrumenting accesses
  (some of those will access stack). The latter is chosen by the current
  implementation
- if CONFIG_VMAP_STACK is selected (and !private_stack) but
  CONFIG_KASAN_VMALLOC is not, those few over-instrumented sites may
  trigger crashes because there's no shadow memory for those

I am now realizing that this situation can't happen for BPF JIT, as
VMAP_STACK depends on :

  !KASAN || KASAN_HW_TAGS || KASAN_VMALLOC
 
So I'll just drop the dependency on VMAP_STACK

Alexis

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com