# Heap pointer can overflow

Unchecked heap pointer addition in OpenVM's bump allocator overflows, letting a crafted large allocation return a pointer overlapping existing heap cells.

- Payout: Contest reward
- Severity: high
- Program: OpenVM
- Credited: Leo Alt
- Disclosed: 2025-03-24
- Write-up quality: 8/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_openvm_january2025.pdf#3.1.13
- Library page: https://bugbountylibrary.com/r/cantina%3Aopenvm_january2025%3A3.1.13
- Tags: domain:oss impact:integrity kind:contest platform:cantina sev:high tech:rust technique:source-review vuln:memory-corruption

**Target:** Rust bump allocator (memory.rs sys_alloc_aligned)
**Root cause:** heap_pos += bytes is performed without overflow checking, so a large allocation wraps the pointer; the SYSTEM-area check only constrains the jump size, not the wrap.
**Steps:**
1. Read attacker-controlled n, compute c = n*2, push into Vec v1.
2. Call `sys_alloc_aligned(4,4)` to get current heap_ptr.
3. Compute `missing = u32::MAX - (heap_ptr as u32)`.
4. Call `sys_alloc_aligned(missing, 4)` to wrap heap_pos past u32::MAX.
5. Call `sys_alloc_aligned((v1.as_ptr() as usize) - 4, 4)` to obtain a pointer overlapping v1's cell.
6. Push into new Vec v2 and observe v1's contents change, proving aliasing.
**How found:** Code review of the bump allocator: noticed heap_pos += bytes lacked overflow check and that the SYSTEM-area guard only bounds the jump magnitude, implying a wrap could bypass it.
**Exploitation:** Attacker supplies a large allocation size (k >= u32::MAX - 0x0c00_0000) via guest input, overflowing the heap pointer so subsequent allocations alias existing heap cells, allowing manipulation of targeted heap regions.
**Insight:** In bump allocators, an unchecked pointer increment plus a range guard is insufficient: the guard constrains the delta, not the wrap. Test by requesting an allocation sized to u32::MAX minus the current pointer to force wraparound into live heap.