Values popped from the stack can be considered as user inputs - and thus, any value can be popped off the stack. Let's consider the example in an opcode where two values are popped from the stack, the mem_offset indicating a memory offset and a size indicating a size to copy from that mem_offset. In that case, the operation mem_offset + size to get the offset of the last element copied can panic, which is certainly not a behavior that should happen : even in such cases, the Cairo VM should not panic.
Panics can only happen in one case: invariants that should never trigger (easier to track, should revert)
In this epic, we'll explicitly check for overflowing operations when executing opcodes and manage their overflowing case by hand
### Tasks
- [ ] https://github.com/kkrt-labs/kakarot-ssj/issues/633
- [ ] Replace all vulnerable operations by using this CheckedOP library and handling the result
Feature Request
Values popped from the stack can be considered as user inputs - and thus, any value can be popped off the stack. Let's consider the example in an opcode where two values are popped from the stack, the
mem_offset
indicating a memory offset and asize
indicating a size to copy from thatmem_offset
. In that case, the operationmem_offset + size
to get the offset of the last element copied can panic, which is certainly not a behavior that should happen : even in such cases, the Cairo VM should not panic.Panics can only happen in one case: invariants that should never trigger (easier to track, should revert)
In this epic, we'll explicitly check for overflowing operations when executing opcodes and manage their overflowing case by hand