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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 24 Jan 2022 18:47:40 +0100 From: Ard Biesheuvel <ardb@...nel.org> To: linux@...linux.org.uk, linux-arm-kernel@...ts.infradead.org Cc: linux-hardening@...r.kernel.org, Ard Biesheuvel <ardb@...nel.org>, Nicolas Pitre <nico@...xnic.net>, Arnd Bergmann <arnd@...db.de>, Kees Cook <keescook@...omium.org>, Keith Packard <keithpac@...zon.com>, Linus Walleij <linus.walleij@...aro.org>, Nick Desaulniers <ndesaulniers@...gle.com>, Tony Lindgren <tony@...mide.com>, Marc Zyngier <maz@...nel.org>, Vladimir Murzin <vladimir.murzin@....com>, Jesse Taube <mr.bossman075@...il.com> Subject: [PATCH v5 28/32] ARM: unwind: disregard unwind info before stack frame is set up When unwinding the stack from a stack overflow, we are likely to start from a stack push instruction, given that this is the most common way to grow the stack for compiler emitted code. This push instruction rarely appears anywhere else than at offset 0x0 of the function, and if it doesn't, the compiler tends to split up the unwind annotations, given that the stack frame layout is apparently not the same throughout the function. This means that, in the general case, if the frame's PC points at the first instruction covered by a certain unwind entry, there is no way the stack frame that the unwind entry describes could have been created yet, and so we are still on the stack frame of the caller in that case. So treat this as a special case, and return with the new PC taken from the frame's LR, without applying the unwind transformations to the virtual register set. This permits us to unwind the call stack on stack overflow when the overflow was caused by a stack push on function entry. Signed-off-by: Ard Biesheuvel <ardb@...nel.org> Tested-by: Keith Packard <keithpac@...zon.com> Tested-by: Marc Zyngier <maz@...nel.org> Tested-by: Vladimir Murzin <vladimir.murzin@....com> # ARMv7M --- arch/arm/kernel/unwind.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c index b7a6141c342f..e8d729975f12 100644 --- a/arch/arm/kernel/unwind.c +++ b/arch/arm/kernel/unwind.c @@ -411,7 +411,21 @@ int unwind_frame(struct stackframe *frame) if (idx->insn == 1) /* can't unwind */ return -URC_FAILURE; - else if ((idx->insn & 0x80000000) == 0) + else if (frame->pc == prel31_to_addr(&idx->addr_offset)) { + /* + * Unwinding is tricky when we're halfway through the prologue, + * since the stack frame that the unwinder expects may not be + * fully set up yet. However, one thing we do know for sure is + * that if we are unwinding from the very first instruction of + * a function, we are still effectively in the stack frame of + * the caller, and the unwind info has no relevance yet. + */ + if (frame->pc == frame->lr) + return -URC_FAILURE; + frame->sp_low = frame->sp; + frame->pc = frame->lr; + return URC_OK; + } else if ((idx->insn & 0x80000000) == 0) /* prel31 to the unwind table */ ctrl.insn = (unsigned long *)prel31_to_addr(&idx->insn); else if ((idx->insn & 0xff000000) == 0x80000000) -- 2.30.2
Powered by blists - more mailing lists