On Tue, 22 Sep 2026 04:15:13 +0200, Kumar Kartikeya Dwivedi wrote: > On Tue Sep 22, 2026 at 3:54 AM CEST, Feng Yang wrote: > > From: Feng Yang <[email protected]> > > > > BPF fexit programs run after the traced function returns, while their > > context still contains the original function argument values. A traced > > function is free to consume an skb argument before returning, so the > > pointer seen by fexit can already be stale. > > > > The verifier checks that the first argument to bpf_skb_output() has the > > BTF type of struct sk_buff, but that does not establish its lifetime. > > bpf_skb_event_output() then dereferences skb->len and can trigger a > > use-after-free. > > > > Do not expose bpf_skb_output() to tracing programs which can run after > > the target: fexit, fexit.multi, fsession and fsession.multi. Keep it > > available to fentry and other tracing attach types where it is already > > supported. fsession must be rejected because the same program runs on > > both entry and return and the verifier cannot prove that a helper call > > is entry-only. > > > > Fixes: fec56f5890d9 ("bpf: Introduce BPF trampoline") > > Reported-by: Quan Sun <[email protected]> > > Reported-by: Yinhao Hu <[email protected]> > > Reported-by: Kaiyan Mei <[email protected]> > > Closes: > > https://lore.kernel.org/all/[email protected]/ > > Signed-off-by: Yun Lu <[email protected]> > > Signed-off-by: Feng Yang <[email protected]> > > --- > > Sorry, this is not an acceptable fix. This negates usage of the function in > all > fexit and fession attach points. Unless there is a simpler way to enumerate in > which attach points this helper should be disabled, it might not be worth > doing > and leaving this be as is. >
Thanks for your reply. That is indeed correct. Moreover, the comment for `bpf_skb_output` in `include/uapi/linux/bpf.h` reads: "This helper is similar to bpf_perf_event_output() but restricted to raw_tracepoint bpf programs.", yet this comment is actually outdated. > pw-bot: cr
