# Garbage collector crash

A regression in mruby's GC reintroduced a use-after-free assertion crash when a Fiber yields a Proc, letting a crafted script abort the interpreter.

- Payout: $300
- Severity: low
- Program: shopify-scripts
- Credited: dgaletic
- Disclosed: 2017-04-15
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/215854
- Library page: https://bugbountylibrary.com/r/h1%3A215854
- Tags: domain:oss impact:dos kind:bounty platform:hackerone sev:low tech:ruby technique:regression vuln:dos vuln:memory-corruption

**Target:** mruby interpreter garbage collector (Fiber/Proc handling)
**Root cause:** Commit ecee8c51 reintroduced a GC bug where a Proc created inside a Fiber that yields it is not correctly marked, so GC.start frees a still-referenced object and mrb_gc_mark hits an MRB_TT_FREE object, tripping the assertion.
**Steps:**
1. Create a Fiber whose body captures Fiber.current and yields `Proc.new {}`
2. Resume the fiber to obtain the Proc
3. Call `GC.start`
4. mruby aborts: `mrb_gc_mark: Assertion (obj)->tt != MRB_TT_FREE failed`
**How found:** Researcher recognized the crash as a reintroduction of a previously reported mruby GitHub issue (#3063) and bisected to commit ecee8c51, confirming presence in later revisions.
**Exploitation:** A malicious script submitted to the sandboxed interpreter triggers the assertion and aborts the mruby process, causing denial of service of the script execution environment.
**Insight:** When a sandboxed interpreter is the security boundary, watch for regressions of previously-fixed GC/memory bugs; a known upstream issue plus a bisect to the reintroducing commit is a fast path to a valid DoS report.
