On Thu, Mar 12, 2026 at 10:24:24AM +0800, Leon Hwang wrote:
> On 12/3/26 06:45, Jiri Olsa wrote:
> > On Tue, Mar 03, 2026 at 11:06:36PM +0800, Leon Hwang wrote:
> >> Uprobe programs that modify regs require different runtime assumptions
> >> than those that do not. Mixing !kprobe_write_ctx progs with
> >> kprobe_write_ctx progs via tail calls could break these assumptions.
> >>
> >> To address this, reject the combination of !kprobe_write_ctx progs with
> >> kprobe_write_ctx progs in bpf_map_owner_matches(), which prevents the
> >> tail callee from modifying regs unexpectedly.
> >
> > hi,
> > could you please give some example where this is actual problem?
> > I'd expect it's up to user (whoever installs the tailcall map) to
> > avoid such situations.
> >
> The self test in patch #6 can verify the problem, that
> kprobe_write_ctx=true progs can be abused to modify struct pt_regs via
> tail calls when tracing kernel functions using kprobe_write_ctx=false prog.
>
> Explain the problem by reusing the test code:
>
> int dummy_run;
> u64 data;
>
> struct {
> __uint(type, BPF_MAP_TYPE_PROG_ARRAY);
> __uint(max_entries, 1);
> __uint(key_size, sizeof(__u32));
> __uint(value_size, sizeof(__u32));
> } prog_array_dummy SEC(".maps");
>
> SEC("?kprobe")
> int dummy_kprobe(void *ctx)
> {
> dummy_run++;
> bpf_tail_call_static(ctx, &prog_array_dummy, 0);
> return 0;
> }
>
> SEC("?kprobe")
> int kprobe(struct pt_regs *regs)
> {
> data = regs->di = 0;
> return 0;
> }
>
> The "kprobe" prog will be added to "prog_array_dummy" map.
>
> In user space, the "dummy_kprobe" prog will attach to kernel function
> "bpf_entry_test1".
>
> Actually, without this patch, when "bpf_fentry_test1" runs, the arg "a"
> will be updated as 0. Thus, bpf_prog_test_run_tracing() returns -EFAULT
> instead of 0.
>
> bpf_prog_test_run_tracing()
> |-->bpf_fentry_test1()
> |-->dummy_kprobe()
> |-->kprobe() /* via tail call */
> |-->regs->di = 0;
> return 1; /* instead of 2 */
> return -EFAULT;
>
> Yep, the commit log is not clear to describe this abuse problem. Will
> update it.
ah right :-\ ok, I think we need to do the suggested one way check and
that should prevent kprobes having writeable ctx
thanks,
jirka
