Re: [PATCH bpf-next v2 1/2] bpf: Fix abuse of kprobe_write_ctx via freplace

[Alexei Starovoitov]

On Mon, Mar 30, 2026 at 9:44 AM Song Liu <song@xxxxxxxxxx> wrote:
>
> On Sun, Mar 29, 2026 at 10:38 PM Leon Hwang <leon.hwang@xxxxxxxxx> wrote:
> >
> > On 28/3/26 05:39, Song Liu wrote:
> > > On Thu, Mar 26, 2026 at 7:17 AM Leon Hwang <leon.hwang@xxxxxxxxx> wrote:
> > [...]
> > >> @@ -3733,6 +3733,11 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog,
> > >>                 tr = prog->aux->dst_trampoline;
> > >>                 tgt_prog = prog->aux->dst_prog;
> > >>         }
> > >> +       if (prog->type == BPF_PROG_TYPE_EXT &&
> > >> +           prog->aux->kprobe_write_ctx != tgt_prog->aux->kprobe_write_ctx) {
> > >> +               err = -EINVAL;
> > >> +               goto out_unlock;
> > >> +       }
> > >
> > > This also blocks uprobe+freplace when prog and tgt_prog have different
> > > kprobe_write_ctx, right? Is this the expected behavior?
> > >
> >
> > Intuitively, yes, this also blocks uprobe+freplace.
> >
> > However, how can we distinguish uprobe/kprobe here?
> >
> > At attach time, uprobe/kprobe is recognized by the target perf event
> > flags instead of BPF prog's expected_attach_type. Thus, we cannot infer
> > the use of prog by prog itself.
>
> Maybe we should introduce an attach type BPF_TRACE_UPROBE in a
> backward compatible way:
> - expected_attach_type = 0, it could be either kprobe or uprobe.
> - expected_attach_type = BPF_TRACE_UPROBE, it must be an uprobe.
>
> With this flag, we can allow uprobe+freplace when the user space sets
> BPF_TRACE_UPROBE properly. WDYT?

New uapi just to fix a narrow bug? Not a good tradeoff.