signal: Remove the bogus sigkill_pending in ptrace_stop
authorEric W. Biederman <ebiederm@xmission.com>
Wed, 1 Sep 2021 18:21:34 +0000 (13:21 -0500)
committerEric W. Biederman <ebiederm@xmission.com>
Wed, 6 Oct 2021 16:26:28 +0000 (11:26 -0500)
commit7d613f9f72ec8f90ddefcae038fdae5adb8404b3
tree22b15f12da8fc87a3a2ddd13422862c8b611f119
parent6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f
signal: Remove the bogus sigkill_pending in ptrace_stop

The existence of sigkill_pending is a little silly as it is
functionally a duplicate of fatal_signal_pending that is used in
exactly one place.

Checking for pending fatal signals and returning early in ptrace_stop
is actively harmful.  It casues the ptrace_stop called by
ptrace_signal to return early before setting current->exit_code.
Later when ptrace_signal reads the signal number from
current->exit_code is undefined, making it unpredictable what will
happen.

Instead rely on the fact that schedule will not sleep if there is a
pending signal that can awaken a task.

Removing the explict sigkill_pending test fixes fixes ptrace_signal
when ptrace_stop does not stop because current->exit_code is always
set to to signr.

Cc: stable@vger.kernel.org
Fixes: 3d749b9e676b ("ptrace: simplify ptrace_stop()->sigkill_pending() path")
Fixes: 1a669c2f16d4 ("Add arch_ptrace_stop")
Link: https://lkml.kernel.org/r/87pmsyx29t.fsf@disp2133
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
kernel/signal.c