Re: [PATCH bpf-next v3 3/6] bpf: Disallow !kprobe_write_ctx progs tail-calling kprobe_write_ctx progs

[Leon Hwang]

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.

Thanks,
Leon