# Crash: calling Proc::initialize_copy with a Proc instance where initialize never ran leads to a crash

Reopening Proc#initialize on a Proc subclass lets initialize_copy copy a Proc whose irep was never set, dereferencing NULL+0x68 in mrb_proc_copy and crashing mruby.

- Payout: $8,000
- Severity: high
- Program: shopify-scripts
- Credited: brakhane
- Disclosed: 2016-12-16
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/184857
- Library page: https://bugbountylibrary.com/r/h1%3A184857
- Tags: domain:oss impact:dos kind:bounty platform:hackerone sev:high tech:ruby technique:source-review vuln:dos vuln:memory-corruption

**Target:** mruby Proc#initialize_copy (mrb_proc_copy in proc.c)
**Root cause:** mrb_proc_copy unconditionally dereferences a->body.irep->refcnt, but a Proc created via Proc.new with a redefined initialize never gets its irep populated, leaving body.irep NULL.
**Steps:**
1. Define `a = Proc.new do end`
2. Reopen `class Proc; def initialize; end; end`
3. Create `b = Proc.new` (initialize runs, irep never set)
4. Call `a.initialize_copy b`
5. mrb_proc_init_copy -> mrb_proc_copy dereferences NULL irep at proc.c:144, SIGSEGV at 0x68
**How found:** Reused the trick from prior report #184661 (redefining initialize to bypass normal object setup) and applied it to Proc, then did a quick code lookup at mrb_proc_copy to confirm the NULL irep dereference.
**Exploitation:** Not weaponized; only a reliable crash/DoS demonstrated. Author speculates NULL+OFFSET deref could potentially be leveraged for code execution but did not investigate.
**Insight:** Redefining a core class's initialize to a no-op lets you construct objects in a half-initialized state; then invoke copy/dup/clone-style methods that assume internal fields (like irep) are populated to reach NULL-deref bugs in the runtime.