summaryrefslogtreecommitdiffstats
path: root/vm.c
diff options
context:
space:
mode:
authorKaz Kylheku <kaz@kylheku.com>2018-04-25 23:40:22 -0700
committerKaz Kylheku <kaz@kylheku.com>2018-04-25 23:40:22 -0700
commitc23fd46d841d8d452c02ae4fc796042f2fb86424 (patch)
tree5a84b6667f2228792d61ca5cd28c969665f2cb51 /vm.c
parent3eca0ce001125b1f7042d2d6fe036f036d0845aa (diff)
downloadtxr-c23fd46d841d8d452c02ae4fc796042f2fb86424.tar.gz
txr-c23fd46d841d8d452c02ae4fc796042f2fb86424.tar.bz2
txr-c23fd46d841d8d452c02ae4fc796042f2fb86424.zip
vm: heap corruption bug.
* vm.c (vm_execute_toplevel): Fix data vector being assigned to the wrong display frame, leaving vm.dspl[1].vec uninitialized. Why is that a problem? Because the VM depends on these vectors when performing the vm_set operation: if a frame register is stored, and the frame has an associated vector, mut_obj is invoked on that vector. Now that there exists the load-time operator, the d regs (which live in dspl[1]) can be mutated. That causes mut_obj to be called with garbage. This was all discovered during testing on PPC64.
Diffstat (limited to 'vm.c')
-rw-r--r--vm.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/vm.c b/vm.c
index 8119fcf0..218d427a 100644
--- a/vm.c
+++ b/vm.c
@@ -999,7 +999,7 @@ val vm_execute_toplevel(val desc)
vm.dspl[0].vec = nil;
vm.dspl[1].mem = vd->data;
- vm.dspl[0].vec = vd->datavec;
+ vm.dspl[1].vec = vd->datavec;
return vm_execute(&vm);
}