On Mon, 07 Sep 2026 04:00:16 +0000 [email protected] wrote: > > diff --git a/arch/x86/include/asm/debugreg.h > > b/arch/x86/include/asm/debugreg.h > > index 854d82b88ff4e..3399e166d3044 100644 > > --- a/arch/x86/include/asm/debugreg.h > > +++ b/arch/x86/include/asm/debugreg.h > [ ... ] > > @@ -125,40 +126,66 @@ static __always_inline bool hw_breakpoint_active(void) > > > > extern void hw_breakpoint_restore(void); > > > > -static __always_inline unsigned long local_db_save(void) > > +static __always_inline void local_db_save(unsigned long *dr7, > > + unsigned int *dr7_seq) > > { > > - unsigned long dr7; > > + do { > > + *dr7_seq = this_cpu_read(cpu_dr7_seq); > > + *dr7 = 0; > > > > - if (cpu_feature_enabled(X86_FEATURE_HYPERVISOR) && > > !hw_breakpoint_active()) > > - return 0; > > - > > - get_debugreg(dr7, 7); > > + if (cpu_feature_enabled(X86_FEATURE_HYPERVISOR) && > > + !hw_breakpoint_active()) > > + return; > > [Severity: High] > This isn't a bug introduced by this patch, but could this early return > in local_db_save() bypass the sequence retry loop? > > If an NMI hits exactly before the return instruction and installs a > breakpoint, the function exits immediately. This leaves the newly installed > hardware breakpoint active during exception handlers like MCE, which could > trigger a recursive #DB exception and lead to a kernel panic.
Wait... but fixing this may leak the DR7 setting to the guest. We need another patch to solve this, which introduce a per-cpu flag to prohibit updating the DR7 during switching to the guest. Thanks, -- Masami Hiramatsu (Google) <[email protected]>
