linux-kernel - Re: [PATCH] Check for ambiguities in create alias ioctl.

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: <491C2119.6000107@redhat.com>
Date:	Thu, 13 Nov 2008 14:44:09 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Glauber Costa <glommer@...hat.com>
CC:	linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH] Check for ambiguities in create alias ioctl.

Glauber Costa wrote:
> The current alias ioctl allows for the creation of
> an alias covering a gpa that already exists. It is invalid,
> because the gpa space needs to be uniquely mapped. So, if
> there's a memory slot covering gpa range 0x123000 to 0x124000,
> and we create an alias from any gpa within that range to a different
> target, we create an essential ambiguity that brings no value at
> the cost of a lot of confusion. Right now this confusion
> manifests itself as a BUG() triggered in the rmaps code path.
>   

> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 7a2aeba..c3b5770 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1591,6 +1591,8 @@ static int kvm_vm_ioctl_set_memory_alias(struct kvm *kvm,
>  {
>  	int r, n;
>  	struct kvm_mem_alias *p;
> +	gfn_t base_gfn;
> +	unsigned long npages;
>  
>  	r = -EINVAL;
>  	/* General sanity checks */
> @@ -1607,12 +1609,18 @@ static int kvm_vm_ioctl_set_memory_alias(struct kvm *kvm,
>  	    < alias->target_phys_addr)
>  		goto out;
>  
> +	base_gfn = alias->guest_phys_addr >> PAGE_SHIFT;
> +	npages = alias->memory_size >> PAGE_SHIFT;
> +
> +	if (gfn_to_memslot(kvm, base_gfn) || gfn_to_memslot(kvm, base_gfn + npages))
> +		goto out;
> +
>   

This says nothing about base_gfn + 17.  Moreover, we don't care if 
base+gfn +npages is mapped - it's outside the half-closed alias range.

Further, a clever attacker would first establish the alias, then the 
memslot, bypassing the checks.  I suggest (a) extracting a function to 
check for range overlap from the memslot code, (b) extending it to check 
for both memslots and aliases, and (c) using it everywhere.

-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/