# SIGSEGV on mruby's mark_tbl() (Invalid memory access)

Crafted mruby script corrupts an instance-variable table pointer, causing SIGSEGV in mark_tbl() during GC and DoS of the Shopify Scripts sandbox.

- Payout: hidden
- Severity: high
- Program: Shopify
- Found by: jpenalbae
- Disclosed: 2016-12-17
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/183239
- Library page: https://bugbountylibrary.com/r/h1%3A183239
- Tags: area:oss domain:oss impact:dos kind:bounty platform:hackerone sev:high tech:ruby technique:fuzzing vuln:dos vuln:memory-corruption

**Target:** mruby engine sandbox (mruby_engine_monitored_eval)
**Root cause:** A crafted script leaves an object's iv table pointer (t=0x17) invalid, so mrb_gc_mark_iv/mark_tbl dereferences it during incremental GC marking.
**Steps:**
1. Run the sandbox: `bin/sandbox /tmp/mark_tbl.min2.rb`
2. Script: `t0me=%\nArray.new(9){t0me.empty?s=Array.new(9){%{}*0\ns=Array.dup.new(23)\nArray(0)}\nArray(0..6)}`
3. GC triggers during mrb_instance_new -> mrb_obj_alloc -> mrb_incremental_gc
4. mark_tbl() dereferences t=0x17 and SIGSEGVs at variable.c:403
**How found:** Fuzzing/experimenting with mruby array/block constructs in the sandbox until a GC-time crash surfaced; gdb backtrace pinpointed mark_tbl with t=0x17.
**Exploitation:** Attacker submits the crafted Ruby script to the sandboxed eval; GC marking crashes the process, denying service to the sandbox host.
**Insight:** GC-time crashes in embedded interpreters often stem from partially-initialized objects reachable during incremental marking; odd constructs like `Array.dup.new` and nested blocks can leave iv table pointers unset before allocation triggers GC.