lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 24 May 2020 00:38:27 -0400 From: Keno Fischer <keno@...iacomputing.com> To: linux-arm-kernel@...ts.infradead.org Cc: will@...nel.org, catalin.marinas@....com, oleg@...hat.com, linux-kernel@...r.kernel.org Subject: [PATCH] arm64: ptrace: Fix PTRACE_SINGLESTEP into signal handler Executing PTRACE_SINGLESTEP at a signal stop is special. It is supposed to step merely the signal setup work that the kernel does, but not any instructions in user space. Since not all architectures have the ability to generate a single-step exception directly upon return from user-space, there is a generic pseudo-single-step-stop that may be used for this purpose (tracehook_signal_handler). Now, arm64 does have the ability to generate single-step exceptions directly upon return to userspace and was using this capability (rather than the generic pseudo-trap) to obtain a similar effect. However, there is actually a subtle difference that becomes noticeable when the signal handler in question attempts to block SIGTRAP (either because it is set in sa_mask, or because it is a handler for SIGTRAP itself and SA_NODEFER is not set). In such a situation, a real single step exception will cause the SIGTRAP signal to be forcibly unblocked and the signal disposition to be reset to SIG_DFL. The generic pseudo-single-step does not suffer from this problem, because the SIGTRAP it delivers is not real. The arm64 behavior is problematic, because a forced reset of the signal disposition can be quite disruptive to the userspace program. This patch brings the arm64 behavior in line with the other major architectures by using the generic pseudo-single-step-stop, avoiding the problematic interaction with SIGTRAP masks. Fixes: 2c020ed8 ("arm64: Signal handling support") Signed-off-by: Keno Fischer <keno@...iacomputing.com> --- arch/arm64/kernel/signal.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c index 339882db5a91..cf237ee9443b 100644 --- a/arch/arm64/kernel/signal.c +++ b/arch/arm64/kernel/signal.c @@ -808,14 +808,7 @@ static void handle_signal(struct ksignal *ksig, struct pt_regs *regs) */ ret |= !valid_user_regs(®s->user_regs, current); - /* - * Fast forward the stepping logic so we step into the signal - * handler. - */ - if (!ret) - user_fastforward_single_step(tsk); - - signal_setup_done(ret, ksig, 0); + signal_setup_done(ret, ksig, test_thread_flag(TIF_SINGLESTEP)); } /* -- 2.25.1
Powered by blists - more mailing lists