# Crash: Overwriting NoMethodError with a builtin class crashes/corrupts memory

Reassigning NoMethodError to a builtin class in mruby causes infinite recursion in mrb_no_method_error, overflowing the stack and corrupting GC memory, crashing the sandbox.

- Payout: $10,000
- Severity: high
- Program: shopify-scripts
- Credited: brakhane
- Disclosed: 2017-03-01
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/186723
- Library page: https://bugbountylibrary.com/r/h1%3A186723
- Tags: domain:oss impact:dos kind:bounty platform:hackerone sev:high tech:ruby technique:source-review vuln:dos vuln:memory-corruption

**Target:** mruby sandbox (mruby-engine) error handling / GC
**Root cause:** mrb_no_method_error calls `new` on the NoMethodError class; if NoMethodError is reassigned to a builtin class lacking `new`, that call itself raises NoMethodError, recursing infinitely until stack overflow corrupts GC context stack.
**Steps:**
1. Run in mruby sandbox: `NoMethodError = Fixnum`
2. Trigger any missing method: `boom!`
3. Observe infinite recursion in mrb_no_method_error -> mrb_method_missing -> mrb_bob_missing
4. Stack overflow leads to SIGSEGV in mark_context_stack during GC
**How found:** Researcher was fuzzing/testing the mruby.science sandbox and accidentally broke it; traced the crash via gdb backtrace showing repeated mrb_no_method_error frames and a segfault in mark_context_stack during GC.
**Exploitation:** Attacker submits the two-line script to the sandboxed mruby evaluation service; the recursion overflows the C stack and corrupts GC roots, crashing the process (DoS).
**Insight:** Reassigning core exception classes (or any class whose `new` is invoked internally by the runtime's error path) can turn error handling into unbounded recursion; check whether error constructors depend on user-mutable class bindings.