From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@redhat.com>
Subject: Re: [PATCH] KVM: prevent read from desc->shadow_ptes[-1] in rmap_desc_remove_entry()
Date: Sat, 29 Aug 2009 20:57:01 +0300
Message-ID: <4A996BED.3040702@redhat.com>
References: <4A991B64.3050903@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kvm@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>
To: Roel Kluin <roel.kluin@gmail.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:13492 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751581AbZH2R4j (ORCPT <rfc822;kvm@vger.kernel.org>);
	Sat, 29 Aug 2009 13:56:39 -0400
In-Reply-To: <4A991B64.3050903@gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 08/29/2009 03:13 PM, Roel Kluin wrote:
> prevent read from desc->shadow_ptes[-1]
>
> Signed-off-by: Roel Kluin<roel.kluin@gmail.com>
> ---
> If in rmap_remove() (bottom) we do:
>
> while (desc) {
>          for (i = 0; i<  RMAP_EXT&&  desc->shadow_ptes[i]; ++i)
>                  if (desc->shadow_ptes[i] == spte) {
>                          rmap_desc_remove_entry(rmapp,
>                                                 desc, i,
>                                                 prev_desc);
>                          return;
>                  }
>          prev_desc = desc;
>          desc = desc->more;
> }
>
> If in the first iteration esc->shadow_ptes[0] == spte, then we
> call rmap_desc_remove_entry() with i == 0, and then we read in
> the last iteration from desc->shadow_ptes[-1].
>
> I found this by code analysis.
>
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index 0ef5bb2..e1b2e46 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -541,7 +541,7 @@ static void rmap_desc_remove_entry(unsigned long *rmapp,
>   {
>   	int j;
>
> -	for (j = RMAP_EXT - 1; !desc->shadow_ptes[j]&&  j>  i; --j)
> +	for (j = RMAP_EXT - 1; j>  i&&  !desc->shadow_ptes[j]; --j)
>   		;
>   	desc->shadow_ptes[i] = desc->shadow_ptes[j];
>   	desc->shadow_ptes[j] = NULL;
>    

There is never a case when j < 0.  The loop finds the highest j that has 
a non-NULL shadow_pte[j], and that is guaranteed to exist.

I think the j > i test is redundant.  Not sure though.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.