Re: SIGILL and uretprobes, WAS: [PATCH] uprobes: Free utask on dup_return_instance() failure

[Andrii Nakryiko]

On Wed, Aug 26, 2026 at 4:49 AM Oleg Nesterov <oleg@xxxxxxxxxx> wrote:
>
> On 08/25, Andrii Nakryiko wrote:
> >
> > On Tue, Aug 25, 2026 at 9:38 AM Andrii Nakryiko
> > <andrii.nakryiko@xxxxxxxxx> wrote:
> > >
> > > On Tue, Aug 25, 2026 at 5:27 AM Oleg Nesterov <oleg@xxxxxxxxxx> wrote:
> > > >
> > > > On 08/24, Andrii Nakryiko wrote:
> > > > >
> > > > > On Mon, Aug 24, 2026 at 8:57 AM Oleg Nesterov <oleg@xxxxxxxxxx> wrote:
> > > > > >
> > > > > > force_exit_sig(SIGILL) can't be ignored too. But I am fine either way.
> > > > >
> > > > > Current SIGILL sending is already pretty bad behavior that bites us
> > > > > periodically, instead of doubling down on killing the user space
> > > > > process because something about installing uprobe goes wrong, let's
> > > > > think about a bit less destructive way to do this. Mark uprobe for a
> > > > > particular process as defunct or "detaching it", or something along
> > > > > those lines. But not just kill innocent processes.
> > > >
> > > > Well. Yes, SIGILL sending acts as BUG_ON(), this is not nice and
> > >
> > > The problem is that this is actually not a bug but a very real and
> > > expected behavior with user-space using fibers or coroutines. Any
> > > suggestions how we can make this less violent, as it's actually quite
> > > dangerous and kills production applications when someone (unknowingly)
> > > tries to uretprobe trace them...
> > >
> >
> > IIUC, this SIGILL and coroutines/fibers issue is due to
> > uprobe_handle_trampoline not finding utrask->return_instances, because
> > a bit earlier we threw out pending uretprobes due to
> > arch_uretprobe_is_alive() returned false due to that `regs->sp <=
> > ret->stack` check (for x86-64).
>
> Well, unless I am totally confused this is another thing...
>
> Yes, arch_uretprobe_is_alive() sucks, it assumes the single stack.
>
> And I do not know how to fix this problem... uprobe_handle_trampoline()
> must fix regs->ip correctly somehow, otherwise it is pointless to contunue.
>

Argh, I completely forgot about regs->ip fix up, sorry.

> Note also that the current instruction_pointer_set(ri->orig_ret_vaddr)
> can be wrong if the probed task switches its stack.
>
> And we have the same problems with sigaltstack().
>
> ATM, I don't see any solution, and I don't really understand what do
> you propose...
>

Well, conceptually, I'd like us to try to find correct return_instance
instead of assuming the last one in the list is the one we want.
Whether that's technically sound, is a good question, I haven't done a
very thorough home work on this, sorry.

But we do have all pending return instances, and they record original
stack pointer, maybe we can do something with that? On user function
return, stack pointer should match what we had when we installed
return_instance, isn't that right? So in normal/happy case we'll do
what we do today, but if we find our that return_instance is "not
valid", we keep searching across all pending return instances. That's
going to be slower for sure, but at least it a) won't kill the app and
b) will be immensely useful.

> Oleg.
>