From nobody Sun Feb 8 14:59:43 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DF668C7EE22 for ; Thu, 18 May 2023 11:00:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230255AbjERLAS (ORCPT ); Thu, 18 May 2023 07:00:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39112 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230035AbjERLAP (ORCPT ); Thu, 18 May 2023 07:00:15 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 417EFE8; Thu, 18 May 2023 04:00:14 -0700 (PDT) Date: Thu, 18 May 2023 11:00:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1684407612; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lf71vhO9lf29YzQJAZ4ACIGDyA0p6fAMMkxfCnAYrcE=; b=dAtyqeTOHCLCWEz8OUgpnrAeWAiV3Dr4EEp2foF8lBUfJA85jU7Frisc6dorpzeJDdiroZ JauTgflRI+rH8pz+bOCunIMgo677F5GZ8pyU/eDzuSSV+bhN7Or4gWSCuCG0CKzd0BD0KQ XN+9uLQ6sKNMgq76F1AOG/Q/xp1EavshAQmNKwksWpzvUbKQiM0l8OMGDWiQhuHbrUQDe+ 4p9sPkuVM9kw5xtdBwFjCE4D6RSPKZb2fJpzPuhh6Z3rsjELvoNZQZVWtMZgmOFQMP4yLT HQKR4eio/RRFInULc7mnHD2kp/T/z+KtjL/gzsbE01wU7OjHoDfm+coKN0CLrw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1684407612; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lf71vhO9lf29YzQJAZ4ACIGDyA0p6fAMMkxfCnAYrcE=; b=WbNaLUOCDzNvGm9jwS5P0hRHsIzmPcJPQolqVGaDeNg/uqcov2Ayfn6NyE0YsCElonrTUR JEY7BZrOlZg3e1DQ== From: "tip-bot2 for Vernon Lovejoy" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: objtool/urgent] x86/show_trace_log_lvl: Ensure stack pointer is aligned, again Cc: Vernon Lovejoy , Oleg Nesterov , Josh Poimboeuf , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20230512104232.GA10227@redhat.com> References: <20230512104232.GA10227@redhat.com> MIME-Version: 1.0 Message-ID: <168440761130.404.15489106698238873699.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The following commit has been merged into the objtool/urgent branch of tip: Commit-ID: 2e4be0d011f21593c6b316806779ba1eba2cd7e0 Gitweb: https://git.kernel.org/tip/2e4be0d011f21593c6b316806779ba1eb= a2cd7e0 Author: Vernon Lovejoy AuthorDate: Fri, 12 May 2023 12:42:32 +02:00 Committer: Josh Poimboeuf CommitterDate: Tue, 16 May 2023 06:31:04 -07:00 x86/show_trace_log_lvl: Ensure stack pointer is aligned, again The commit e335bb51cc15 ("x86/unwind: Ensure stack pointer is aligned") tried to align the stack pointer in show_trace_log_lvl(), otherwise the "stack < stack_info.end" check can't guarantee that the last read does not go past the end of the stack. However, we have the same problem with the initial value of the stack pointer, it can also be unaligned. So without this patch this trivial kernel module #include static int init(void) { asm volatile("sub $0x4,%rsp"); dump_stack(); asm volatile("add $0x4,%rsp"); return -EAGAIN; } module_init(init); MODULE_LICENSE("GPL"); crashes the kernel. Fixes: e335bb51cc15 ("x86/unwind: Ensure stack pointer is aligned") Signed-off-by: Vernon Lovejoy Signed-off-by: Oleg Nesterov Link: https://lore.kernel.org/r/20230512104232.GA10227@redhat.com Signed-off-by: Josh Poimboeuf --- arch/x86/kernel/dumpstack.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c index 0bf6779..f18ca44 100644 --- a/arch/x86/kernel/dumpstack.c +++ b/arch/x86/kernel/dumpstack.c @@ -195,7 +195,6 @@ static void show_trace_log_lvl(struct task_struct *task= , struct pt_regs *regs, printk("%sCall Trace:\n", log_lvl); =20 unwind_start(&state, task, regs, stack); - stack =3D stack ? : get_stack_pointer(task, regs); regs =3D unwind_get_entry_regs(&state, &partial); =20 /* @@ -214,9 +213,13 @@ static void show_trace_log_lvl(struct task_struct *tas= k, struct pt_regs *regs, * - hardirq stack * - entry stack */ - for ( ; stack; stack =3D PTR_ALIGN(stack_info.next_sp, sizeof(long))) { + for (stack =3D stack ?: get_stack_pointer(task, regs); + stack; + stack =3D stack_info.next_sp) { const char *stack_name; =20 + stack =3D PTR_ALIGN(stack, sizeof(long)); + if (get_stack_info(stack, task, &stack_info, &visit_mask)) { /* * We weren't on a valid stack. It's possible that