On Wed, 2024-10-23 at 09:15 -0700, Andrii Nakryiko wrote:
[...]
> > diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> > index 4513372c5bc8..1bb6c6def04d 100644
> > --- a/include/linux/bpf_verifier.h
> > +++ b/include/linux/bpf_verifier.h
> > @@ -773,8 +773,11 @@ struct bpf_verifier_env {
> > * since the last time the function state was printed
> > */
> > u32 scratched_regs;
> > - /* Same as scratched_regs but for stack slots */
> > - u64 scratched_stack_slots;
> > + /* Same as scratched_regs but for stack slots. The stack size may
> > + * temporarily exceed MAX_BPF_STACK (e.g., due to fastcall pattern
> > + * in check_stack_slot_within_bounds()), so two u64 values are used.
> > + */
> > + u64 scratched_stack_slots[2];
>
> We have other places where we assume that 64 bits is enough to specify
> stack slot index (linked regs, for instance). Do we need to update all
> of those now as well? If yes, maybe then it's better to make sure
> valid programs can never go beyond 512 bytes of stack even for
> bpf_fastcall?..
Specifically function frames.
This is a huge blunder from my side.
