# Heap use-after-free during range creation

mruby's OP_RANGE used stale stack pointer after mrb_funcall in range_check triggered stack realloc, causing heap use-after-free write during range creation.

- Payout: $200
- Severity: low
- Program: shopify-scripts
- Credited: titanous
- Disclosed: 2017-02-07
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/194884
- Library page: https://bugbountylibrary.com/r/h1%3A194884
- Tags: domain:oss impact:dos kind:bounty platform:hackerone sev:low tech:ruby technique:source-review vuln:dos vuln:memory-corruption

**Target:** mruby VM OP_RANGE / range_check
**Root cause:** OP_RANGE evaluates mrb_range_new with regs[b] arguments; range_check calls mrb_funcall for the equivalence test, which can extend the stack and realloc it, but the VM then writes the result into the old (freed) regs pointer.
**Steps:**
1. Build mruby with ASAN.
2. Run `[][0,0]..[1, 1, 1, ... (many elements)]` so the range endpoint array has many elements.
3. range_check invokes mrb_funcall for equivalence test, triggering stack_extend_alloc/realloc.
4. VM writes range result into stale regs pointer -> heap-use-after-free write of size 16.
**How found:** Code review of OP_RANGE in vm.c: noticed mrb_range_new can call mrb_funcall (range_check) which may reallocate the stack, invalidating the regs pointer used for the subsequent assignment.
**Exploitation:** Not demonstrated; author notes it may be exploitable but did not explore further. Crash only.
**Insight:** In VM interpreters, any opcode that calls back into user code (mrb_funcall) between reading and writing registers can invalidate the cached stack/regs pointer if the stack grows; audit OP_* handlers for this pattern.