libkvm: null pointer dereference in kvm_destroy_phys_mem

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

---
 libkvm/libkvm.c |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

index 93d7b6b..8f7a34f 100644
@@ -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

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'

---
 libkvm/libkvm.c |    7 +++----
 1 files changed, 3 insertions(+), 4 deletions(-)

index 93d7b6b..fc2e265 100644
@@ -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

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

if this part of the patch is applied..

this warning will be triggered in the next compile.

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

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