diff options
author | Kaz Kylheku <kaz@kylheku.com> | 2018-04-25 23:40:22 -0700 |
---|---|---|
committer | Kaz Kylheku <kaz@kylheku.com> | 2018-04-25 23:40:22 -0700 |
commit | c23fd46d841d8d452c02ae4fc796042f2fb86424 (patch) | |
tree | 5a84b6667f2228792d61ca5cd28c969665f2cb51 /vm.c | |
parent | 3eca0ce001125b1f7042d2d6fe036f036d0845aa (diff) | |
download | txr-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.c | 2 |
1 files changed, 1 insertions, 1 deletions
@@ -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); } |