# heap use-after-free in mrb_vm_exec()

Recursive super call in mruby's M.new re-enters mrb_vm_exec, reallocating the VM stack and leaving a dangling pointer that memcpy writes to.

- Payout: hidden
- Severity: high
- Program: Shopify
- Found by: mg36
- Disclosed: 2017-05-13
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/216700
- Library page: https://bugbountylibrary.com/r/h1%3A216700
- Tags: area:oss domain:oss kind:bounty platform:hackerone sev:high tech:ruby technique:source-review vuln:dos vuln:memory-corruption

**Target:** mruby VM (mrb_vm_exec stack handling)
**Root cause:** Calling super inside M.new re-enters mrb_instance_new/mrb_funcall_with_block, which triggers stack_extend realloc and frees the VM stack region while mrb_vm_exec still holds a pointer to it, then memcpy writes to the freed stack.
**Steps:**
1. Build mruby with ASAN.
2. Run the script: `class M` / `def M.new(r)` / `super` / `new(0)` / `end` / `end` / `M.new(0)`.
3. Observe ASAN heap-use-after-free WRITE of size 12 in mrb_vm_exec at vm.c:1454 via __asan_memcpy.
**How found:** Author crafted a recursive super/new pattern to force VM stack reallocation during mrb_vm_exec, then confirmed with ASAN.
**Insight:** Recursive re-entry into object construction (super inside .new calling new again) can reallocate the VM stack mid-execution; fuzz interpreter stack-extend paths with self-referential constructors under ASAN.