When the n parameter is less than 24, there is no segfault. However,
investigating with a memory sanitizer shows that uninitialized read errors
start to happen when n >= 15. The uninitialized read happens at the following
location in vm.c (with the relevant line marked):
If the above POC doesn't crash the sandbox reliably, try increasing the n parameter (it crashes for me with n = 30). Also, a small correction: the memory errors and segfault are caused by holding onto the old mrb->c->ci pointer in the ci variable after the calls to ecall which sometimes reallocate into a different block. The call to cipop needed to be moved so the fix can work because cipop modifies mrb->c->ci.
The text was updated successfully, but these errors were encountered:
Dinko Galetic and Denis Kasak reported the following (via https://hackerone.com/dgaletic):
The following code produces a segfault without causing a stack overflow, affecting the sandbox:
When the
n
parameter is less than 24, there is no segfault. However,investigating with a memory sanitizer shows that uninitialized read errors
start to happen when
n >= 15
. The uninitialized read happens at the followinglocation in vm.c (with the relevant line marked):
The issue seems to be in using the
ci
data after the call tocipop
. The following patch stops the read errors and segfaults, and passes make test:Update:
If the above POC doesn't crash the sandbox reliably, try increasing the n parameter (it crashes for me with n = 30). Also, a small correction: the memory errors and segfault are caused by holding onto the old
mrb->c->ci
pointer in theci
variable after the calls toecall
which sometimes reallocate into a different block. The call tocipop
needed to be moved so the fix can work becausecipop
modifiesmrb->c->ci
.The text was updated successfully, but these errors were encountered: