[BUG] bpf: Tracing progs on the stack save subtree can result in OOM

[BUG] bpf: Tracing progs on the stack save subtree can result in OOM

[Mahnur A]

Hi,

I hit the following case on the current mainline kernel (7.1-rc7)

BPF tracing programs that allocate something and have a deferred-free for it:
Attached to any function in the stack save / unwind result in OOM.


KASAN, slub_debug etc. all save a stack on every alloc/free.
An example bpf program updates a map element,
before lookup and retrieval of the timer object.
It then calls bpf_timer_init().
If this happens at every alloc/free event,
a new timer object gets allocated with every map element update,
while the previous one is deferred-free (via kfree_rcu).

All these alloc/free cause cascading probes to fire which in turn trigger more.
The timer objects accumulate without bound.
kfree_rcu()'d timer objects are reclaimed at a slower rate (or RCU stalls).
This results in OOM which eventually kills init.

Please find the reproducer, config files and the full backtrace here:
https://gist.github.com/MahnurA/622d0cd44df686e241a4b043023871a2

A possible patch could be to not allow BPF programs to attach to such
points at all,
but I'm not sure how that would scale.
I’m happy to test debug patches or provide additional information.

Best regards,
Mahnur

Re: [BUG] bpf: Tracing progs on the stack save subtree can result in OOM

[Alexei Starovoitov]

On Tue Jun 9, 2026 at 10:04 AM PDT, Mahnur A wrote:
> Hi,
>
> I hit the following case on the current mainline kernel (7.1-rc7)
>
> BPF tracing programs that allocate something and have a deferred-free for it:
> Attached to any function in the stack save / unwind result in OOM.
>
>
> KASAN, slub_debug etc. all save a stack on every alloc/free.
> An example bpf program updates a map element,
> before lookup and retrieval of the timer object.
> It then calls bpf_timer_init().
> If this happens at every alloc/free event,
> a new timer object gets allocated with every map element update,
> while the previous one is deferred-free (via kfree_rcu).

It's a known design constraint.
A bunch of things in the kernel need call_rcu().
bpf is not immune to such requirements.

Re: [BUG] bpf: Tracing progs on the stack save subtree can result in OOM

[Mahnur A]

> It's a known design constraint.
> A bunch of things in the kernel need call_rcu().
> bpf is not immune to such requirements.

I'm sorry, perhaps I don't understand your answer.
I get that rcu has its usages and is required.
My concern is:
Should bpf tracing programs be allowed to attach
to stack walk/ unwinding functions?
When any memory debugging mechanism is enabled
it will trigger any bpf program attached anywhere here
to run and keep running an exponential amount of times.