All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: linux-trace-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v14 01/14] x86/mce: Fix hardware debug register corruption on task migration
Date: Sun, 30 Aug 2026 14:40:05 +0000	[thread overview]
Message-ID: <20260830144005.C28ED1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <178810002334.64882.15357388305843450280.stgit@devnote2>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Moving local_db_save() inside exc_machine_check_kernel() exposes early #MC entry code to hardware breakpoints, partially reverting commit cd840e424f27 and allowing nested #DB exceptions that can fatally corrupt the #DB IST stack.
--

commit 22e84ef34bc3d02a04e2e3356bffad4d11749a7a
Author: Masami Hiramatsu (Google) <mhiramat@kernel.org>

x86/mce: Fix hardware debug register corruption on task migration

In exc_machine_check_user(), local_db_save() and local_db_restore() are
invoked in the outer entry stubs, surrounding exc_machine_check_user().
However, exc_machine_check_user() handles pending thread work and may
schedule(), causing the task to migrate to another CPU. This patch moves
local_db_save() and local_db_restore() inside exc_machine_check_user()
and exc_machine_check_kernel() to prevent hardware debug register corruption.

> diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
> index cfb74be19994d..61ade8b5c9d7b 100644
> --- a/arch/x86/kernel/cpu/mce/core.c
> +++ b/arch/x86/kernel/cpu/mce/core.c
> @@ -2108,6 +2108,7 @@ bool filter_mce(struct mce *m)
>  static __always_inline void exc_machine_check_kernel(struct pt_regs *regs)
>  {
>  	irqentry_state_t irq_state;
> +	unsigned long dr7;
>  
>  	WARN_ON_ONCE(user_mode(regs));
>  
> @@ -2118,18 +2119,24 @@ static __always_inline void exc_machine_check_kernel(struct pt_regs *regs)
>  	if (mca_cfg.initialized && mce_check_crashing_cpu())
>  		return;
>  
> +	dr7 = local_db_save();

[Severity: High]
Does moving local_db_save() below the early checks in
exc_machine_check_kernel() expose this early #MC entry code to hardware
breakpoints?

If a privileged user sets a hardware data breakpoint on a kernel variable
accessed here, such as mca_cfg.initialized or variables inside
mce_check_crashing_cpu(), a #DB exception could fire in kernel mode.

If a Machine Check Exception (#MC) then occurs and preempts the #DB handler,
it switches to the #MC IST stack. Because local_db_save() is not called
until after these variable accesses, the code could trigger a nested #DB
exception.

Since x86 uses a fixed-size Interrupt Stack Table (IST) for #DB exceptions
that unconditionally resets the stack pointer to the top of the #DB IST
stack, wouldn't the nested #DB overwrite the active stack frame of the
interrupted #DB handler, leading to a fatal crash when it attempts to
return?

Could local_db_save() be called at the very beginning of
exc_machine_check_kernel() to prevent this IST stack corruption?

>  	irq_state = irqentry_nmi_enter(regs);
>  
>  	do_machine_check(regs);

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/178810001186.64882.2161016469449127450.stgit@devnote2?part=1

  reply	other threads:[~2026-08-30 14:40 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-30 14:26 [PATCH v14 00/14] tracing: wprobe: x86: Add wprobe for watchpoint Masami Hiramatsu (Google)
2026-08-30 14:27 ` [PATCH v14 01/14] x86/mce: Fix hardware debug register corruption on task migration Masami Hiramatsu (Google)
2026-08-30 14:40   ` sashiko-bot [this message]
2026-09-06 13:03     ` Masami Hiramatsu
2026-08-30 14:27 ` [PATCH v14 02/14] tracing/probes: Fix BTF kflag check for anonymous struct member access Masami Hiramatsu (Google)
2026-08-30 14:38   ` sashiko-bot
2026-08-31  1:24     ` Masami Hiramatsu
2026-08-30 14:27 ` [PATCH v14 03/14] kprobes: Protect kprobe_blacklist with RCU Masami Hiramatsu (Google)
2026-08-30 14:33   ` sashiko-bot
2026-09-02  1:30   ` Masami Hiramatsu
2026-08-30 14:27 ` [PATCH v14 04/14] x86/hw_breakpoints: Make DR7 updates NMI safe Masami Hiramatsu (Google)
2026-08-30 14:45   ` sashiko-bot
2026-09-06 15:28     ` Masami Hiramatsu
2026-08-30 14:27 ` [PATCH v14 05/14] x86/hw_breakpoints: Add arch_modify_local_hw_breakpoint_addr() API Masami Hiramatsu (Google)
2026-08-30 14:38   ` sashiko-bot
2026-09-06 15:42     ` Masami Hiramatsu
2026-08-30 14:27 ` [PATCH v14 06/14] HWBP: Add modify_local_hw_breakpoint_addr() API Masami Hiramatsu (Google)
2026-08-30 14:40   ` sashiko-bot
2026-09-06 15:43     ` Masami Hiramatsu
2026-08-30 14:28 ` [PATCH v14 07/14] tracing/wprobe: Add wprobe (watchpoint probe) trace event support Masami Hiramatsu (Google)
2026-08-30 14:42   ` sashiko-bot
2026-08-30 14:28 ` [PATCH v14 08/14] x86: hw_breakpoint: Add a kconfig to clarify when a breakpoint fires Masami Hiramatsu (Google)
2026-08-30 14:33   ` sashiko-bot
2026-08-30 14:28 ` [PATCH v14 09/14] selftests: tracing: Add a basic testcase for wprobe Masami Hiramatsu (Google)
2026-08-30 14:34   ` sashiko-bot
2026-08-30 14:28 ` [PATCH v14 10/14] selftests: tracing: Add syntax " Masami Hiramatsu (Google)
2026-08-30 14:37   ` sashiko-bot
2026-08-30 14:28 ` [PATCH v14 11/14] tracing/wprobe: Add set_wprobe and clear_wprobe event triggers Masami Hiramatsu (Google)
2026-08-30 14:52   ` sashiko-bot
2026-09-06 15:50     ` Masami Hiramatsu
2026-08-30 14:29 ` [PATCH v14 12/14] selftests: ftrace: Add wprobe trigger testcase Masami Hiramatsu (Google)
2026-08-30 14:44   ` sashiko-bot
2026-08-30 14:29 ` [PATCH v14 13/14] tracing/wprobe: Support BTF typecast in fetchargs Masami Hiramatsu (Google)
2026-08-30 14:44   ` sashiko-bot
2026-08-30 14:29 ` [PATCH v14 14/14] tracing/wprobe: Support BTF struct offset resolution in set_wprobe trigger Masami Hiramatsu (Google)
2026-08-30 14:46   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260830144005.C28ED1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.