* [PATCH v2 bpf-next 1/2] bpf: Reject bpf_skb_output() from return-side tracing
@ 2026-09-22 1:54 Feng Yang
2026-09-22 1:54 ` [PATCH v2 bpf-next 2/2] selftests/bpf: Check bpf_skb_output() tracing restrictions Feng Yang
2026-09-22 2:15 ` [PATCH v2 bpf-next 1/2] bpf: Reject bpf_skb_output() from return-side tracing Kumar Kartikeya Dwivedi
0 siblings, 2 replies; 5+ messages in thread
From: Feng Yang @ 2026-09-22 1:54 UTC (permalink / raw)
To: kpsingh, matt, song, jolsa, ihor.solodrai, ast, daniel, andrii,
eddyz87, memxor, martin.lau, yonghong.song, emil, rostedt,
mhiramat, mathieu.desnoyers
Cc: bpf, linux-kernel, linux-trace-kernel
From: Feng Yang <yangfeng@kylinos.cn>
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 <2022090917019@std.uestc.edu.cn>
Reported-by: Yinhao Hu <dddddd@hust.edu.cn>
Reported-by: Kaiyan Mei <M202472210@hust.edu.cn>
Closes: https://lore.kernel.org/all/9d61b891-2d52-42b9-bc1a-ad963ccb675d@std.uestc.edu.cn/
Signed-off-by: Yun Lu <luyun@kylinos.cn>
Signed-off-by: Feng Yang <yangfeng@kylinos.cn>
---
v2: Add inline.
v1: https://lore.kernel.org/all/20260920063442.499577-1-yangfeng59949@163.com/
---
kernel/trace/bpf_trace.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 29260951aa87..29c83e2938cd 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -1339,6 +1339,20 @@ static inline bool is_trace_fsession(const struct bpf_prog *prog)
prog->expected_attach_type == BPF_TRACE_FSESSION_MULTI);
}
+static inline bool tracing_prog_may_run_after_target(const struct bpf_prog *prog)
+{
+ /* The target may consume pointer arguments before these programs run. */
+ switch (prog->expected_attach_type) {
+ case BPF_TRACE_FEXIT:
+ case BPF_TRACE_FEXIT_MULTI:
+ case BPF_TRACE_FSESSION:
+ case BPF_TRACE_FSESSION_MULTI:
+ return true;
+ default:
+ return false;
+ }
+}
+
static const struct bpf_func_proto *
kprobe_prog_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
{
@@ -1730,6 +1744,8 @@ tracing_prog_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
switch (func_id) {
#ifdef CONFIG_NET
case BPF_FUNC_skb_output:
+ if (tracing_prog_may_run_after_target(prog))
+ return NULL;
return &bpf_skb_output_proto;
case BPF_FUNC_xdp_output:
return &bpf_xdp_output_proto;
--
2.27.0
^ permalink raw reply [flat|nested] 5+ messages in thread* [PATCH v2 bpf-next 2/2] selftests/bpf: Check bpf_skb_output() tracing restrictions 2026-09-22 1:54 [PATCH v2 bpf-next 1/2] bpf: Reject bpf_skb_output() from return-side tracing Feng Yang @ 2026-09-22 1:54 ` Feng Yang 2026-09-22 2:46 ` bot+bpf-ci 2026-09-22 2:15 ` [PATCH v2 bpf-next 1/2] bpf: Reject bpf_skb_output() from return-side tracing Kumar Kartikeya Dwivedi 1 sibling, 1 reply; 5+ messages in thread From: Feng Yang @ 2026-09-22 1:54 UTC (permalink / raw) To: kpsingh, matt, song, jolsa, ihor.solodrai, ast, daniel, andrii, eddyz87, memxor, martin.lau, yonghong.song, emil, rostedt, mhiramat, mathieu.desnoyers Cc: bpf, linux-kernel, linux-trace-kernel From: Feng Yang <yangfeng@kylinos.cn> Add verifier coverage for the bpf_skb_output() tracing policy. Verify that an fentry program can still use the helper, while the equivalent fexit program is rejected at load time. Signed-off-by: Yun Lu <luyun@kylinos.cn> Signed-off-by: Feng Yang<yangfeng@kylinos.cn> --- .../bpf/progs/verifier_helper_restricted.c | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/tools/testing/selftests/bpf/progs/verifier_helper_restricted.c b/tools/testing/selftests/bpf/progs/verifier_helper_restricted.c index 889c9b78b912..058e71927cd5 100644 --- a/tools/testing/selftests/bpf/progs/verifier_helper_restricted.c +++ b/tools/testing/selftests/bpf/progs/verifier_helper_restricted.c @@ -3,6 +3,7 @@ #include <linux/bpf.h> #include <bpf/bpf_helpers.h> +#include <bpf/bpf_tracing.h> #include "bpf_misc.h" struct val { @@ -17,6 +18,13 @@ struct { __type(value, struct val); } map_spin_lock SEC(".maps"); +struct { + __uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY); + __uint(max_entries, 1); + __type(key, __u32); + __type(value, __u32); +} perf_event_map SEC(".maps"); + SEC("kprobe") __description("bpf_ktime_get_coarse_ns is forbidden in BPF_PROG_TYPE_KPROBE") __failure __msg("program of this type cannot use helper bpf_ktime_get_coarse_ns") @@ -165,4 +173,28 @@ l0_%=: exit; \ : __clobber_all); } +SEC("fentry/skb_tx_error") +__description("bpf_skb_output is allowed in BPF_TRACE_FENTRY") +__success +int BPF_PROG(skb_output_fentry, void *skb) +{ + __u64 meta = 0; + + bpf_skb_output(skb, &perf_event_map, BPF_F_CURRENT_CPU, + &meta, sizeof(meta)); + return 0; +} + +SEC("fexit/skb_tx_error") +__description("bpf_skb_output is forbidden in BPF_TRACE_FEXIT") +__failure __msg("program of this type cannot use helper bpf_skb_output") +int BPF_PROG(skb_output_fexit, void *skb) +{ + __u64 meta = 0; + + bpf_skb_output(skb, &perf_event_map, BPF_F_CURRENT_CPU, + &meta, sizeof(meta)); + return 0; +} + char _license[] SEC("license") = "GPL"; -- 2.27.0 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2 bpf-next 2/2] selftests/bpf: Check bpf_skb_output() tracing restrictions 2026-09-22 1:54 ` [PATCH v2 bpf-next 2/2] selftests/bpf: Check bpf_skb_output() tracing restrictions Feng Yang @ 2026-09-22 2:46 ` bot+bpf-ci 0 siblings, 0 replies; 5+ messages in thread From: bot+bpf-ci @ 2026-09-22 2:46 UTC (permalink / raw) To: yangfeng59949, kpsingh, matt, song, jolsa, ihor.solodrai, ast, daniel, andrii, eddyz87, memxor, martin.lau, yonghong.song, emil, rostedt, mhiramat, mathieu.desnoyers Cc: bpf, linux-kernel, linux-trace-kernel, ast, andrii, daniel, martin.lau, eddyz87, yonghong.song, mason, ihor.solodrai [-- Attachment #1: Type: text/plain, Size: 4181 bytes --] > commit 586c31fe079529e232f3760545b476754b91501b > Author: Feng Yang <yangfeng@kylinos.cn> > AuthorDate: Tue Sep 22 09:54:17 2026 +0800 > Commit: Kernel Patches Daemon <kernel-patches-bot@fb.com> > CommitDate: Mon Sep 21 19:02:48 2026 -0700 > > selftests/bpf: Check bpf_skb_output() tracing restrictions > > Add verifier coverage for the bpf_skb_output() tracing policy. Verify > that an fentry program can still use the helper, while the equivalent > fexit program is rejected at load time. > > Signed-off-by: Yun Lu <luyun@kylinos.cn> > Signed-off-by: Feng Yang<yangfeng@kylinos.cn> There's a formatting issue in the second Signed-off-by line - it's missing the space between the name and email address. Should this be: Signed-off-by: Feng Yang <yangfeng@kylinos.cn> instead of "Feng Yang<yangfeng@kylinos.cn>"? > diff --git a/tools/testing/selftests/bpf/progs/verifier_helper_restricted.c b/tools/testing/selftests/bpf/progs/verifier_helper_restricted.c > index 889c9b78b912e..058e71927cd5c 100644 > --- a/tools/testing/selftests/bpf/progs/verifier_helper_restricted.c > +++ b/tools/testing/selftests/bpf/progs/verifier_helper_restricted.c > @@ -3,6 +3,7 @@ > > #include <linux/bpf.h> > #include <bpf/bpf_helpers.h> > +#include <bpf/bpf_tracing.h> > #include "bpf_misc.h" > > struct val { > @@ -17,6 +18,13 @@ struct { > __type(value, struct val); > } map_spin_lock SEC(".maps"); > > +struct { > + __uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY); > + __uint(max_entries, 1); > + __type(key, __u32); > + __type(value, __u32); > +} perf_event_map SEC(".maps"); > + [ ... ] > @@ -165,4 +173,28 @@ l0_%=: exit; \ > : __clobber_all); > } > > +SEC("fentry/skb_tx_error") > +__description("bpf_skb_output is allowed in BPF_TRACE_FENTRY") > +__success > +int BPF_PROG(skb_output_fentry, void *skb) > +{ > + __u64 meta = 0; > + > + bpf_skb_output(skb, &perf_event_map, BPF_F_CURRENT_CPU, > + &meta, sizeof(meta)); > + return 0; > +} > + > +SEC("fexit/skb_tx_error") > +__description("bpf_skb_output is forbidden in BPF_TRACE_FEXIT") > +__failure __msg("program of this type cannot use helper bpf_skb_output") > +int BPF_PROG(skb_output_fexit, void *skb) > +{ > + __u64 meta = 0; > + > + bpf_skb_output(skb, &perf_event_map, BPF_F_CURRENT_CPU, > + &meta, sizeof(meta)); > + return 0; > +} > + > char _license[] SEC("license") = "GPL"; The kernel change this tests (538d3dadf8d0e) gates bpf_skb_output() on four attach types in tracing_prog_may_run_after_target(): case BPF_TRACE_FEXIT: case BPF_TRACE_FEXIT_MULTI: case BPF_TRACE_FSESSION: case BPF_TRACE_FSESSION_MULTI: return true; Only BPF_TRACE_FEXIT gets a test case here. Would it make sense to add coverage for BPF_TRACE_FEXIT_MULTI, BPF_TRACE_FSESSION and BPF_TRACE_FSESSION_MULTI as well? The fsession case in particular is the one whose rationale the parent commit message spends a paragraph on - that 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. All three have libbpf section prefixes available (tools/lib/bpf/libbpf.c has "fsession+", "fsession.multi+", "fexit.multi+"), so the extra test cases would be copies of the existing fexit block with different SEC() strings. Kumar Kartikeya Dwivedi raised a design concern about the overall approach in v2: https://lore.kernel.org/all/DLLHE9PBLDU0.XQGEOQQIR4HV@gmail.com/ "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." The concern is that disabling bpf_skb_output() in all fexit/fsession programs may be too broad. Since this test verifies the blanket restriction that was rejected, has this feedback been addressed? --- AI reviewed your patch. Please fix the bug or email reply why it's not a bug. See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md CI run summary: https://github.com/kernel-patches/bpf/actions/runs/35678199634 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2 bpf-next 1/2] bpf: Reject bpf_skb_output() from return-side tracing 2026-09-22 1:54 [PATCH v2 bpf-next 1/2] bpf: Reject bpf_skb_output() from return-side tracing Feng Yang 2026-09-22 1:54 ` [PATCH v2 bpf-next 2/2] selftests/bpf: Check bpf_skb_output() tracing restrictions Feng Yang @ 2026-09-22 2:15 ` Kumar Kartikeya Dwivedi 2026-09-22 7:03 ` Feng Yang 1 sibling, 1 reply; 5+ messages in thread From: Kumar Kartikeya Dwivedi @ 2026-09-22 2:15 UTC (permalink / raw) To: Feng Yang, kpsingh, matt, song, jolsa, ihor.solodrai, ast, daniel, andrii, eddyz87, martin.lau, yonghong.song, emil, rostedt, mhiramat, mathieu.desnoyers Cc: bpf, linux-kernel, linux-trace-kernel On Tue Sep 22, 2026 at 3:54 AM CEST, Feng Yang wrote: > From: Feng Yang <yangfeng@kylinos.cn> > > 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 <2022090917019@std.uestc.edu.cn> > Reported-by: Yinhao Hu <dddddd@hust.edu.cn> > Reported-by: Kaiyan Mei <M202472210@hust.edu.cn> > Closes: https://lore.kernel.org/all/9d61b891-2d52-42b9-bc1a-ad963ccb675d@std.uestc.edu.cn/ > Signed-off-by: Yun Lu <luyun@kylinos.cn> > Signed-off-by: Feng Yang <yangfeng@kylinos.cn> > --- 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. pw-bot: cr > [...] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2 bpf-next 1/2] bpf: Reject bpf_skb_output() from return-side tracing 2026-09-22 2:15 ` [PATCH v2 bpf-next 1/2] bpf: Reject bpf_skb_output() from return-side tracing Kumar Kartikeya Dwivedi @ 2026-09-22 7:03 ` Feng Yang 0 siblings, 0 replies; 5+ messages in thread From: Feng Yang @ 2026-09-22 7:03 UTC (permalink / raw) To: memxor Cc: andrii, ast, bpf, daniel, eddyz87, emil, ihor.solodrai, jolsa, kpsingh, linux-kernel, linux-trace-kernel, martin.lau, mathieu.desnoyers, matt, mhiramat, rostedt, song, yangfeng59949, yonghong.song 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 <yangfeng@kylinos.cn> > > > > 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 <2022090917019@std.uestc.edu.cn> > > Reported-by: Yinhao Hu <dddddd@hust.edu.cn> > > Reported-by: Kaiyan Mei <M202472210@hust.edu.cn> > > Closes: https://lore.kernel.org/all/9d61b891-2d52-42b9-bc1a-ad963ccb675d@std.uestc.edu.cn/ > > Signed-off-by: Yun Lu <luyun@kylinos.cn> > > Signed-off-by: Feng Yang <yangfeng@kylinos.cn> > > --- > > 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-09-22 7:04 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2026-09-22 1:54 [PATCH v2 bpf-next 1/2] bpf: Reject bpf_skb_output() from return-side tracing Feng Yang 2026-09-22 1:54 ` [PATCH v2 bpf-next 2/2] selftests/bpf: Check bpf_skb_output() tracing restrictions Feng Yang 2026-09-22 2:46 ` bot+bpf-ci 2026-09-22 2:15 ` [PATCH v2 bpf-next 1/2] bpf: Reject bpf_skb_output() from return-side tracing Kumar Kartikeya Dwivedi 2026-09-22 7:03 ` Feng Yang
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®