Re: [PATCH bpf-next v3] bpf: Clamp trace length in __bpf_get_stack to fix OOB write

[Lecomte, Arnaud]

On 13/11/2025 12:49, Brahmajit Das wrote:
> On 12.11.2025 08:40, 'Lecomte, Arnaud' via syzkaller-bugs wrote:
> > I am a not sure this is the right solution and I am scared that by
> > forcing this clamping, we are hiding something else.
> > If we have a look at the code below:
> > ```
> >
> > |
> >
> > 	if (trace_in) {
> > 		trace = trace_in;
> > 		trace->nr = min_t(u32, trace->nr, max_depth);
> > 	} else if (kernel && task) {
> > 		trace = get_callchain_entry_for_task(task, max_depth);
> > 	} else {
> > 		trace = get_perf_callchain(regs, kernel, user, max_depth,
> > 					crosstask, false, 0);
> > 	} ``` trace should be (if I remember correctly) clamped there. If not, it
> > might hide something else. I would like to have a look at the return for
> > each if case through gdb. |
> Hi Arnaud,
> So I've been debugging this the reproducer always takes the else branch
> so trace holds whatever get_perf_callchain returns; in this situation.
>
> I mostly found it to be a value around 4.
>
> In some case the value would exceed to something 27 or 44, just after
> the code block
>
> 	if (unlikely(!trace) || trace->nr < skip) {
> 		if (may_fault)
> 			rcu_read_unlock();
> 		goto err_fault;
> 	}
>
> So I'm assuming there's some race condition that might be going on
> somewhere.
Which value ? trace->nr ?
> I'm still debugging bug I'm open to ideas and definitely I could be
> wrong here, please feel free to correct/point out.

I should be able to have a look tomorrow evening as I am currently a bit 
overloaded
with my work.

Thanks,
Arnaud