On Mon, Sep 30, 2024 at 02:36:08PM -0700, Andrii Nakryiko wrote:

SNIP

quoted

 struct bpf_uprobe_multi_link {

@@ -3248,9 +3260,13 @@ uprobe_multi_link_handler(struct uprobe_consumer *con, struct pt_regs *regs,
                          __u64 *data)
 {
        struct bpf_uprobe *uprobe;
+       int ret;

        uprobe = container_of(con, struct bpf_uprobe, consumer);
-       return uprobe_prog_run(uprobe, instruction_pointer(regs), regs);
+       ret = uprobe_prog_run(uprobe, instruction_pointer(regs), regs);
+       if (uprobe->session)
+               return ret ? UPROBE_HANDLER_IGNORE : 0;
+       return ret;

isn't this a bug that BPF program can return arbitrary value here and,
e.g., request uprobe unregistration?

Let's return 0, unless uprobe->session? (it would be good to move that
into a separate patch with Fixes)

yea there's no use case for uprobe multi user, so let's return
0 as you suggest

quoted

 }

 static int

@@ -3260,6 +3276,12 @@ uprobe_multi_link_ret_handler(struct uprobe_consumer *con, unsigned long func, s
        struct bpf_uprobe *uprobe;

        uprobe = container_of(con, struct bpf_uprobe, consumer);
+       /*
+        * There's chance we could get called with NULL data if we registered uprobe
+        * after it hit entry but before it hit return probe, just ignore it.
+        */
+       if (uprobe->session && !data)
+               return 0;

why can't handle_uretprobe_chain() do this check instead? We know when
we are dealing with session uprobe/uretprobe, so we can filter out
these spurious calls, no?

right, now that we decide session based on presence of both callbacks
we have that info in here handle_uretprobe_chain.. but let's still check
it for sanity and warn? like

        if (WARN_ON_ONCE(uprobe->session && !data))
                return 0;

jirka