linux-kernel - Re: [PATCH 1/2] x86/amd_node: fix integer divide by zero during init

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251204164533.GB983706@yaz-khff2.amd.com>
Date: Thu, 4 Dec 2025 11:45:33 -0500
From: Yazen Ghannam <yazen.ghannam@....com>
To: Borislav Petkov <bp@...en8.de>
Cc: Steven Noonan <steven@...inklabs.net>, linux-kernel@...r.kernel.org,
	Ariadne Conill <ariadne@...adne.space>, x86@...r.kernel.org,
	stable@...r.kernel.org
Subject: Re: [PATCH 1/2] x86/amd_node: fix integer divide by zero during init

On Wed, Dec 03, 2025 at 10:18:13PM +0100, Borislav Petkov wrote:
> On Fri, Nov 14, 2025 at 07:57:35PM +0000, Steven Noonan wrote:
> > On a Xen dom0 boot, this feature does not behave, and we end up
> > calculating:
> > 
> >     num_roots = 1
> >     num_nodes = 2
> >     roots_per_node = 0
> > 
> > This causes a divide-by-zero in the modulus inside the loop.
> > 
> > This change adds a couple of guards for invalid states where we might
> > get a divide-by-zero.
> > 
> > Signed-off-by: Steven Noonan <steven@...inklabs.net>
> > Signed-off-by: Ariadne Conill <ariadne@...adne.space>
> > CC: Yazen Ghannam <yazen.ghannam@....com>
> > CC: x86@...r.kernel.org
> > CC: stable@...r.kernel.org
> > ---
> >  arch/x86/kernel/amd_node.c | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/arch/x86/kernel/amd_node.c b/arch/x86/kernel/amd_node.c
> > index 3d0a4768d603c..cdc6ba224d4ad 100644
> > --- a/arch/x86/kernel/amd_node.c
> > +++ b/arch/x86/kernel/amd_node.c
> > @@ -282,6 +282,17 @@ static int __init amd_smn_init(void)
> 
> That better not be loading at all on a X86_FEATURE_HYPERVISOR configuration.
> 

Right, so we need a !hypervisor check.

I'm not familiar with the Xen implementation. Does it expect the dom0
guest to be effectively the same as bare metal? Basically, this would
act as the 'management' VM that touch hardware?

Thanks,
Yazen