[PATCH] libkvm: null pointer dereference in kvm_destroy_phys_mem

[PATCH] libkvm: null pointer dereference in kvm_destroy_phys_mem

[Carlo Marcelo Arenas Belon]

The following patch eliminates the uninitialized mem pointer in 
kvm_destroy_phys_mem and uses instead the corresponding entry from the 
slots array in the conditional to fix :

  libkvm.c:580: warning: 'mem' is used uninitialized in this function

Signed-off-by: Carlo Marcelo Arenas Belon <carenas-kLeDWSohozoJb6fo7hG9ng@public.gmane.org>
---
 libkvm/libkvm.c |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
index 93d7b6b..8f7a34f 100644
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -567,7 +567,6 @@ void kvm_destroy_phys_mem(kvm_context_t kvm, unsigned long phys_start,
 			  unsigned long len)
 {
 	int slot;
-	struct kvm_memory_region *mem;
 
 	slot = get_slot(phys_start);
 
@@ -579,8 +578,8 @@ void kvm_destroy_phys_mem(kvm_context_t kvm, unsigned long phys_start,
 	if (phys_start != slots[slot].phys_addr) {
 		fprintf(stderr,
 			"WARNING: %s: phys_start is 0x%lx expecting 0x%llx\n",
-			__FUNCTION__, phys_start, mem->guest_phys_addr);
-		phys_start = mem->guest_phys_addr;
+			__FUNCTION__, phys_start, slots[slot].phys_addr);
+		phys_start = slots[slot].phys_addr;
 	}
 	kvm_create_phys_mem(kvm, phys_start, 0, 0, 0);
 }
-- 
1.5.2.5


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

[PATCH] [RESEND] libkvm: NULL pointer dereference in kvm_destroy_phys_mem as used in kvm-56

[Carlo Marcelo Arenas Belon]

The following patch eliminates the uninitialized mem pointer, using 
instead the corresponding entry from the slots array to fix :

  libkvm.c:580: warning: 'mem' is used uninitialized in this function

Also changes the formatting type for phys_addr to long to prevent :

  libkvm.c:581: warning: format '%llx' expects type 'long long unsigned int'
, but argument 5 has type 'long unsigned int'

Signed-off-by: Carlo Marcelo Arenas Belon <carenas-kLeDWSohozoJb6fo7hG9ng@public.gmane.org>
---
 libkvm/libkvm.c |    7 +++----
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
index 93d7b6b..fc2e265 100644
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -567,7 +567,6 @@ void kvm_destroy_phys_mem(kvm_context_t kvm, unsigned long phys_start,
 			  unsigned long len)
 {
 	int slot;
-	struct kvm_memory_region *mem;
 
 	slot = get_slot(phys_start);
 
@@ -578,9 +577,9 @@ void kvm_destroy_phys_mem(kvm_context_t kvm, unsigned long phys_start,
 	}
 	if (phys_start != slots[slot].phys_addr) {
 		fprintf(stderr,
-			"WARNING: %s: phys_start is 0x%lx expecting 0x%llx\n",
-			__FUNCTION__, phys_start, mem->guest_phys_addr);
-		phys_start = mem->guest_phys_addr;
+			"WARNING: %s: phys_start is 0x%lx expecting 0x%lx\n",
+			__FUNCTION__, phys_start, slots[slot].phys_addr);
+		phys_start = slots[slot].phys_addr;
 	}
 	kvm_create_phys_mem(kvm, phys_start, 0, 0, 0);
 }
-- 
1.5.2.5


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Re: [PATCH] [RESEND] libkvm: NULL pointer dereference in kvm_destroy_phys_mem as used in kvm-56

[Avi Kivity]

Carlo Marcelo Arenas Belon wrote:
> The following patch eliminates the uninitialized mem pointer, using 
> instead the corresponding entry from the slots array to fix :
>
>   libkvm.c:580: warning: 'mem' is used uninitialized in this function
>
> Also changes the formatting type for phys_addr to long to prevent :
>
>   libkvm.c:581: warning: format '%llx' expects type 'long long unsigned int'
> , but argument 5 has type 'long unsigned int'
>
>   

Applied, thanks.  But please avoid unrelated changes in the same patch 
in the future.

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


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Re: [PATCH] [RESEND] libkvm: NULL pointer dereference in kvm_destroy_phys_mem as used in kvm-56

[Avi Kivity]

Carlo Marcelo Arenas Belon wrote:
> so just to be clear on this?, would you rather have these changes in a patch
> series, or as unrelated patches with the second one fixing a formatting issue
> that the first one triggered?
>   

Oh, I misunderstood.  The changes are related and should be in one 
patch.  Sorry about the confusion.


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


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Re: [PATCH] [RESEND] libkvm: NULL pointer dereference in kvm_destroy_phys_mem as used in kvm-56

[Carlo Marcelo Arenas Belon]

On Tue, Dec 18, 2007 at 06:20:03PM +0200, Avi Kivity wrote:
> Carlo Marcelo Arenas Belon wrote:
> > The following patch eliminates the uninitialized mem pointer, using 
> > instead the corresponding entry from the slots array to fix :
> >
> >   libkvm.c:580: warning: 'mem' is used uninitialized in this function

if this part of the patch is applied..

> > Also changes the formatting type for phys_addr to long to prevent :
> >
> >   libkvm.c:581: warning: format '%llx' expects type 'long long unsigned int'
> > , but argument 5 has type 'long unsigned int'

this warning will be triggered in the next compile.

> Applied, thanks.  But please avoid unrelated changes in the same patch 
> in the future.

sorry about that, will do, even if I disagree there were unrelated as
explained above.

so just to be clear on this?, would you rather have these changes in a patch
series, or as unrelated patches with the second one fixing a formatting issue
that the first one triggered?

if the later, how to handle in that case the dependency so that they don't get
applied in incorrect order triggering conflicts?

I understand that the first part of it has higher importance than the second
one, but I would rather have them applied together as they make IMHO more
sense as an atomic change.

Carlo

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace