Re: [PATCH RFC bpf-next 2/8] bpf: mark instructions accessing program stack

On Thu, Jun 4, 2026 at 5:23=E2=80=AFAM Alexis Lothor=C3=A9
<[email protected]> wrote:
>
> On Sat Apr 25, 2026 at 7:05 AM CEST, sashiko-bot wrote:
>
> [...]
>
> >>  #define LR_FRAMENO_BITS     3
> >>  #define LR_SPI_BITS 6
> > [ ... ]
> >> @@ -6493,6 +6498,8 @@ static int check_mem_access(struct bpf_verifier_=
env *env, int insn_idx, u32 regn
> >>              else
> >>                      err =3D check_stack_write(env, regno, off, size,
> >>                                              value_regno, insn_idx);
> >> +
> >> +            mark_insn_accesses_stack(env, insn_idx);
> >
> > Global subprograms are verified independently of their call sites, and =
pointer
> > arguments are tracked as PTR_TO_MEM rather than PTR_TO_STACK. Inside th=
e
> > subprogram, check_mem_access() evaluates loads and stores under the
> > PTR_TO_MEM branch, which does not invoke mark_insn_accesses_stack().
> >
> > If a BPF caller dynamically passes a pointer to its stack as an argumen=
t to
> > the global subprogram, will the JIT-compiled global subprogram execute =
with
> > KASAN checks enabled for those accesses?
> >
> > Does this erroneously monitor the BPF stack, bypassing the intended
> > suppression mechanism?
>
> After having thought about this one for quite some time, I see no
> simple way to correctly distinguish stack accesses hidden behing a
> PTR_TO_MEM passed to a global subprog, as those are verified separately.
>
> I can either:
> 1. skip PTR_TO_MEM memory instrumentation when we are in global
> subprograms, at the risk of missing instrumentation on passed memory
> accesses that _need_ to be instrumented
> 2. systematically instrument passed PTR_TO_MEM memory accesses in global
> subprog, at the risk of inserting unneeded instrumentation when the
> passed memory comes in fact from caller memory.
>
> I then propose to be conservative and apply 2:  the only downside I can
> think of is that a few alwasy-passing kasan checks will be inserted, but
> we are at least sure not to miss any instrumentation.

Isn't it the other way around? Replacing LDX with asan_load() will
check stack access, but it doesn't have shadow memory behind it?
Or you mean to assume kasan_vmalloc and vmalloced_stack kconfig?