# Null pointer dereference in mrb_class

Crafted nested module/ensure/yield mruby code causes null pointer dereference and out-of-bounds stack reads in mrb_class and mrb_vm_exec, crashing the sandbox.

- Payout: $800
- Severity: low
- Program: shopify-scripts
- Credited: dgaletic
- Disclosed: 2017-03-14
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/212107
- Library page: https://bugbountylibrary.com/r/h1%3A212107
- Tags: domain:oss impact:dos kind:bounty platform:hackerone sev:low tech:ruby technique:fuzzing technique:source-review vuln:dos vuln:memory-corruption

**Target:** mruby interpreter / mruby-engine sandbox
**Root cause:** Nested module/ensure/yield constructs corrupt the VM stack so mrb_class dereferences a null RObject pointer and mrb_vm_exec reads past the allocated stack buffer.
**Steps:**
1. Feed the nested `module A ... ensure ... yield ... end` payload to mruby/mruby-engine
2. Observe segfault in mrb_class (class.h:50) with mrb_obj_ptr(v) == 0x0
3. Run under Valgrind to see two invalid reads at vm.c:1867 with m1=r=m2=0
4. Note Valgrind changes behavior to LocalJumpError instead of segfault
**How found:** Fuzzing/constructing unusual nested module+ensure+yield control flow, then debugging the segfault in gdb and Valgrind to trace the null RObject and out-of-bounds stack pointer.
**Exploitation:** Attacker submits crafted mruby script to the sandboxed Shopify Scripts engine, causing interpreter crash (DoS) via null deref and OOB stack reads.
**Insight:** Deeply nested ensure blocks combined with yield can desync the VM's environment/stack bookkeeping (cipop/mrb_env_unshare); target interpreter stack invariants around exception unwinding rather than input parsing.