linux-kernel - Re: [PATCH] KVM: arm64: Fix error path in init_hyp

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] [day] [month] [year] [list]

Message-ID: <aFvqyl-Xquuoyvh1@google.com>
Date: Wed, 25 Jun 2025 12:25:46 +0000
From: Mostafa Saleh <smostafa@...gle.com>
To: Quentin Perret <qperret@...gle.com>
Cc: linux-kernel@...r.kernel.org, kvmarm@...ts.linux.dev,
	linux-arm-kernel@...ts.infradead.org, maz@...nel.org,
	oliver.upton@...ux.dev, joey.gouly@....com, suzuki.poulose@....com,
	yuzenghui@...wei.com, catalin.marinas@....com, will@...nel.org
Subject: Re: [PATCH] KVM: arm64: Fix error path in init_hyp_mode()

On Wed, Jun 25, 2025 at 12:22:45PM +0000, Quentin Perret wrote:
> On Wednesday 25 Jun 2025 at 11:33:01 (+0000), Mostafa Saleh wrote:
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > index 38a91bb5d4c7..5bb36c3b06b5 100644
> > --- a/arch/arm64/kvm/arm.c
> > +++ b/arch/arm64/kvm/arm.c
> > @@ -2344,15 +2344,22 @@ static void __init teardown_hyp_mode(void)
> >  	int cpu;
> >  
> >  	free_hyp_pgds();
> > +	/* Order matches the order of initialization init_hyp_mode() */
> >  	for_each_possible_cpu(cpu) {
> > +		if (!per_cpu(kvm_arm_hyp_stack_base, cpu))
> > +			continue;
> >  		free_pages(per_cpu(kvm_arm_hyp_stack_base, cpu), NVHE_STACK_SHIFT - PAGE_SHIFT);
> > +
> > +		if (!kvm_nvhe_sym(kvm_arm_hyp_percpu_base)[cpu])
> > +			continue;
> >  		free_pages(kvm_nvhe_sym(kvm_arm_hyp_percpu_base)[cpu], nvhe_percpu_order());
> >  
> >  		if (free_sve) {
> >  			struct cpu_sve_state *sve_state;
> >  
> >  			sve_state = per_cpu_ptr_nvhe_sym(kvm_host_data, cpu)->sve_state;
> > -			free_pages((unsigned long) sve_state, pkvm_host_sve_state_order());
> > +			if (sve_state)
> > +				free_pages((unsigned long) sve_state, pkvm_host_sve_state_order());
> 
> I'm a bit confused by these extra checks -- free_pages() should be safe
> to call on NULL?

Yes, I surprised in my testing I didn't see an issue with freeing NULL, I
though it might be config related, but I should have looked more.

> 
> IIUC correctly, the actual issue is that per_cpu_ptr_nvhe_sym() will
> dereference the per-cpu pages to find the sve state, which is entirely
> bogus if the per-cpu pages have not been allocated. Now, looking at
> this, it looks like the bigger problem is that we literally free the
> per-cpu pages right before the sve state...
> 
> Should we at least change the freeing order here?

Make sense, I will fix that in v2.

Thanks,
Mostafa

> 
> Thanks,
> Quentin