# NULL pointer dereference in `mrb_check_frozen`

Calling remove_instance_variable on an integer in mruby passes the integer value as a pointer to mrb_check_frozen, causing a NULL/attacker-controlled pointer dereference and crash.

- Payout: $1,000
- Severity: medium
- Program: shopify-scripts
- Credited: dgaletic
- Disclosed: 2019-09-04
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/621308
- Library page: https://bugbountylibrary.com/r/h1%3A621308
- Tags: domain:oss impact:data-leak impact:dos kind:bounty platform:hackerone sev:medium tech:ruby technique:source-review vuln:dos vuln:memory-corruption

**Target:** mruby interpreter (mrb_obj_remove_instance_variable / mrb_iv_remove)
**Root cause:** mrb_obj_remove_instance_variable does not verify the receiver is a heap object before calling mrb_iv_remove, which passes the immediate value (FIXNUM) as a void* to mrb_check_frozen, dereferencing an attacker-controlled address.
**Steps:**
1. Run `mruby -e "3735928559.remove_instance_variable '@a'"`
2. Observe SIGSEGV in mrb_check_frozen at mruby.h:1192
3. Confirm via gdb that `o` equals the integer value (0xdeadbeef)
4. Repeat with any integer including 0 to confirm attacker-controlled address
**How found:** Likely fuzzing or manual review of kernel.c methods that assume a heap object receiver; valgrind flagged the invalid read at 0xdeadbeef, and gdb confirmed the FIXNUM value was used as a pointer.
**Exploitation:** Attacker supplies a script to the mruby sandbox (shopify-scripts) calling remove_instance_variable on an integer; the interpreter dereferences the integer as a pointer, crashing the process (DoS) and potentially reading attacker-chosen memory.
**Insight:** Methods that operate on instance variables (remove_instance_variable, instance_variable_get/set) must type-check the receiver; immediate values like FIXNUM/SYMBOL/NIL are not heap objects and their raw value flows into pointer dereferences.