linux-kernel - Re: [PATCH] KVM: x86: do not pass poisoned hva to __kvm_set_memory

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]

Date:   Thu, 11 Jun 2020 23:14:01 +0300
From:   Maxim Levitsky <mlevitsk@...hat.com>
To:     Paolo Bonzini <pbonzini@...hat.com>, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org
Subject: Re: [PATCH] KVM: x86: do not pass poisoned hva to
 __kvm_set_memory_region

On Thu, 2020-06-11 at 14:01 -0400, Paolo Bonzini wrote:
> __kvm_set_memory_region does not use the hva at all, so trying to
> catch use-after-delete is pointless and, worse, it fails access_ok
> now that we apply it to all memslots including private kernel ones.
> This fixes an AVIC regression.
> 
> Fixes: 09d952c971a5 ("KVM: check userspace_addr for all memslots", 2020-06-01)
> Reported-by: Maxim Levitsky <mlevitsk@...hat.com>
> Signed-off-by: Paolo Bonzini <pbonzini@...hat.com>
> ---
>  arch/x86/kvm/x86.c | 7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 290784ba63e4..00c88c2f34e4 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -9951,13 +9951,8 @@ int __x86_set_memory_region(struct kvm *kvm, int id, gpa_t gpa, u32 size)
>  		if (!slot || !slot->npages)
>  			return 0;
>  
> -		/*
> -		 * Stuff a non-canonical value to catch use-after-delete.  This
> -		 * ends up being 0 on 32-bit KVM, but there's no better
> -		 * alternative.
> -		 */
> -		hva = (unsigned long)(0xdeadull << 48);
>  		old_npages = slot->npages;
> +		hva = 0;
>  	}
>  
>  	for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) {


Under assumption that we can assume that access_ok(0,0) is safe to assume
to be always true:
Reviewed-by: Maxim Levitsky <mlevitsk@...hat.com>

I also tested exactly this solution when triaging this bug and it works,
but I wasn't sure that this is the correct solution.

Best regards,
	Maxim Levitsky