Closed c4-bot-5 closed 2 months ago
This is not valid. There does exist references to mmap2
in the program text, but they're unreachable. mmap2
is only used by the Go runtime on 386 and arm architectures so they're compiled out for mips32. However, they're still provided in the syscall
package for users. But the op-program doesn't use them. As such, this cannot result in an invalid dispute game resolution.
zobront marked the issue as unsatisfactory: Invalid
Lines of code
https://github.com/code-423n4/2024-07-optimism/blob/70556044e5e080930f686c4e5acde420104bb2c4/packages/contracts-bedrock/src/cannon/MIPS.sol#L151
Vulnerability details
Impact
Incorrect resolution of dispute game - True claim will be resolved as False
Proof of Concept
In
MIPS
vm,mmap
syscall is handled by checking syscall no. 4090. However,mmap2
syscall(4210) is usually used allocate/map memories.Here's code snippet of low-level function
syscall_mmap
. (The assembly below is generated from ELF file built fromop-program-client
)As shown in
.text:000CBB80
,mmap
syscall callsmmap2
syscall.Here's code snippet of low-level
syscall_mmap2
function.As shown in the above code snippet, syscall no 0x1072(4210) is used for mmap. In
MIPS
vm, there's no handling of syscall no 0x1072, thus the post state becomes incorrect which makes true claim to be false at the end.Tools Used
Manual Review
Recommended Mitigation Steps
mmap2
should also be handled inMIPS
vm.Assessed type
Context