| Message ID | 20220518225355.784371-8-ebiederm@xmission.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere, archived |
| Headers | show |
| Series | ptrace: cleanups and calling do_cldstop with only siglock | expand |
On 05/18, Eric W. Biederman wrote: > > The code in ptrace_signal to populate siginfo if the signal number > changed is buggy. If the tracer contined the tracee using > ptrace_detach it is guaranteed to use the real_parent (or possibly a > new tracer) but definitely not the origional tracer to populate si_pid > and si_uid. I guess nobody cares. As the comment says If the debugger wanted something specific in the siginfo structure then it should have updated *info via PTRACE_SETSIGINFO. otherwise I don't think si_pid/si_uid have any value. However the patch looks fine to me, just the word "buggy" looks a bit too strong imo. Oleg.
Oleg Nesterov <oleg@redhat.com> writes: > On 05/18, Eric W. Biederman wrote: >> >> The code in ptrace_signal to populate siginfo if the signal number >> changed is buggy. If the tracer contined the tracee using >> ptrace_detach it is guaranteed to use the real_parent (or possibly a >> new tracer) but definitely not the origional tracer to populate si_pid >> and si_uid. > > I guess nobody cares. As the comment says > > If the debugger wanted something > specific in the siginfo structure then it should > have updated *info via PTRACE_SETSIGINFO. > > otherwise I don't think si_pid/si_uid have any value. No one has complained so it is clearly no one cares. So it is definitely not a regression. Or even anything that needs to be backported. However si_pid and si_uid are defined with SI_USER are defined to be whomever sent the signal. So I would argue by definition those values are wrong. > However the patch looks fine to me, just the word "buggy" looks a bit > too strong imo. I guess I am in general agreement. Perhaps I can just say they values are wrong by definition? Eric
On 06/06, Eric W. Biederman wrote: > > Oleg Nesterov <oleg@redhat.com> writes: > > > However the patch looks fine to me, just the word "buggy" looks a bit > > too strong imo. > > I guess I am in general agreement. Perhaps I can just say they values > are wrong by definition? Up to you. I won't really argue with "buggy". Oleg.
diff --git a/kernel/ptrace.c b/kernel/ptrace.c index 15e93eafa6f0..a24eed725cec 100644 --- a/kernel/ptrace.c +++ b/kernel/ptrace.c @@ -526,6 +526,33 @@ static int ptrace_traceme(void) return ret; } +static void ptrace_set_signr(struct task_struct *child, unsigned int signr) +{ + struct kernel_siginfo *info = child->last_siginfo; + + child->exit_code = signr; + /* + * Update the siginfo structure if the signal has + * changed. If the debugger wanted something + * specific in the siginfo structure then it should + * have updated *info via PTRACE_SETSIGINFO. + */ + if (info && (info->si_signo != signr)) { + clear_siginfo(info); + + if (signr != 0) { + info->si_signo = signr; + info->si_errno = 0; + info->si_code = SI_USER; + rcu_read_lock(); + info->si_pid = task_pid_nr_ns(current, task_active_pid_ns(child)); + info->si_uid = from_kuid_munged(task_cred_xxx(child, user_ns), + current_uid()); + rcu_read_unlock(); + } + } +} + /* * Called with tasklist_lock held for writing. * Unlink a traced task, and clean it up if it was a traced zombie. @@ -579,7 +606,7 @@ static int ptrace_detach(struct task_struct *child, unsigned int data) * tasklist_lock avoids the race with wait_task_stopped(), see * the comment in ptrace_resume(). */ - child->exit_code = data; + ptrace_set_signr(child, data); __ptrace_detach(current, child); write_unlock_irq(&tasklist_lock); @@ -851,7 +878,7 @@ static int ptrace_resume(struct task_struct *child, long request, * wait_task_stopped() after resume. */ spin_lock_irq(&child->sighand->siglock); - child->exit_code = data; + ptrace_set_signr(child, data); child->jobctl &= ~JOBCTL_TRACED; wake_up_state(child, __TASK_TRACED); spin_unlock_irq(&child->sighand->siglock); diff --git a/kernel/signal.c b/kernel/signal.c index e782c2611b64..ff4a52352390 100644 --- a/kernel/signal.c +++ b/kernel/signal.c @@ -2562,24 +2562,6 @@ static int ptrace_signal(int signr, kernel_siginfo_t *info, enum pid_type type) if (signr == 0) return signr; - /* - * Update the siginfo structure if the signal has - * changed. If the debugger wanted something - * specific in the siginfo structure then it should - * have updated *info via PTRACE_SETSIGINFO. - */ - if (signr != info->si_signo) { - clear_siginfo(info); - info->si_signo = signr; - info->si_errno = 0; - info->si_code = SI_USER; - rcu_read_lock(); - info->si_pid = task_pid_vnr(current->parent); - info->si_uid = from_kuid_munged(current_user_ns(), - task_uid(current->parent)); - rcu_read_unlock(); - } - /* If the (new) signal is now blocked, requeue it. */ if (sigismember(¤t->blocked, signr) || fatal_signal_pending(current)) {
The code in ptrace_signal to populate siginfo if the signal number changed is buggy. If the tracer contined the tracee using ptrace_detach it is guaranteed to use the real_parent (or possibly a new tracer) but definitely not the origional tracer to populate si_pid and si_uid. Fix this bug by only updating siginfo from the tracer so that the tracers pid and the tracers uid are always used. If it happens that ptrace_resume or ptrace_detach don't have a signal to continue with clear siginfo. This is a very old bug that has been fixable since commit 1669ce53e2ff ("Add PTRACE_GETSIGINFO and PTRACE_SETSIGINFO") when last_siginfo was introduced and the tracer could change siginfo. Fixes: v2.1.68 History-Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> --- kernel/ptrace.c | 31 +++++++++++++++++++++++++++++-- kernel/signal.c | 18 ------------------ 2 files changed, 29 insertions(+), 20 deletions(-)