Messages in this thread | | | Date | Mon, 26 Apr 2021 17:04:00 -0400 (EDT) | From | Mathieu Desnoyers <> | Subject | Re: [PATCH RESEND] ptrace: make ptrace() fail if the tracee changed its pid unexpectedly |
| |
----- On Apr 26, 2021, at 11:45 AM, Oleg Nesterov oleg@redhat.com wrote:
> Suppose we have 2 threads, the group-leader L and a sub-theread T, > both parked in ptrace_stop(). Debugger tries to resume both threads > and does > > ptrace(PTRACE_CONT, T); > ptrace(PTRACE_CONT, L); > > If the sub-thread T execs in between, the 2nd PTRACE_CONT doesn not > resume the old leader L, it resumes the post-exec thread T which was > actually now stopped in PTHREAD_EVENT_EXEC. In this case the > PTHREAD_EVENT_EXEC event is lost, and the tracer can't know that the > tracee changed its pid. > > This patch makes ptrace() fail in this case until debugger does wait() > and consumes PTHREAD_EVENT_EXEC which reports old_pid. This affects all > ptrace requests except the "asynchronous" PTRACE_INTERRUPT/KILL. > > The patch doesn't add the new PTRACE_ option to not complicate the API, > and I _hope_ this won't cause any noticeable regression: > > - If debugger uses PTRACE_O_TRACEEXEC and the thread did an exec > and the tracer does a ptrace request without having consumed > the exec event, it's 100% sure that the thread the ptracer > thinks it is targeting does not exist anymore, or isn't the > same as the one it thinks it is targeting. > > - To some degree this patch adds nothing new. In the scenario > above ptrace(L) can fail with -ESRCH if it is called after the > execing sub-thread wakes the leader up and before it "steals" > the leader's pid.
Hi Oleg,
Is this something that should also target stable kernels ? AFAIU this change won't break debuggers more that they are already in this scenario. Or maybe it makes them fail in more obvious ways ?
Thanks,
Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
| |