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

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

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 = 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 the
> 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 argument 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.

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