fix(levm): avoid overflow in calldataload #1461
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If the offset is larger than calldata, then there is no data to show. Return 0 to the stack
This error is changed because this casting should never fail; therefore if this ever fails, we want to treat it differently from a "normal" VeryLargeNumber error Suggested-by: Jeremias Salomon <jeremias.salomon@lambdaclass.com>
…o fix/levm/stRandom
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If the offset is larger than calldata, then there is no data to show. Return 0 to the stack
Motivation
The calldata operand tried to cast the value it got as an argument to usize everytime. However, that number could be larger than usize and an error is raised.
Description
This tries to check the offset value before casting it to usize. If the offset value (in U256) is larger than the actual length of contents of the calldata (also in U256), then we simply return 0 (since the offset would've removed all the values from calldata).