* [PATCH] KVM: prevent read from desc->shadow_ptes[-1] in rmap_desc_remove_entry()
@ 2009-08-29 12:13 Roel Kluin
2009-08-29 17:57 ` Avi Kivity
0 siblings, 1 reply; 2+ messages in thread
From: Roel Kluin @ 2009-08-29 12:13 UTC (permalink / raw)
To: Avi Kivity, kvm, Andrew Morton
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;
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] KVM: prevent read from desc->shadow_ptes[-1] in rmap_desc_remove_entry()
2009-08-29 12:13 [PATCH] KVM: prevent read from desc->shadow_ptes[-1] in rmap_desc_remove_entry() Roel Kluin
@ 2009-08-29 17:57 ` Avi Kivity
0 siblings, 0 replies; 2+ messages in thread
From: Avi Kivity @ 2009-08-29 17:57 UTC (permalink / raw)
To: Roel Kluin; +Cc: kvm, Andrew Morton
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-08-29 17:56 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-29 12:13 [PATCH] KVM: prevent read from desc->shadow_ptes[-1] in rmap_desc_remove_entry() Roel Kluin
2009-08-29 17:57 ` Avi Kivity
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.