Headline
CVE-2023-41052: fix: order of evaluation for some builtins by charles-cooper · Pull Request #3583 · vyperlang/vyper
Vyper is a Pythonic Smart Contract Language. In affected versions the order of evaluation of the arguments of the builtin functions uint256_addmod, uint256_mulmod, ecadd and ecmul does not follow source order. This behaviour is problematic when the evaluation of one of the arguments produces side effects that other arguments depend on. A patch is currently being developed on pull request #3583. When using builtins from the list above, users should make sure that the arguments of the expression do not produce side effects or, if one does, that no other argument is dependent on those side effects.
ecadd, ecmul, addmod, mulmod
in the case that the arguments have side effects, they could be evaluated out of order
chainsec june 2023 review 5.1
patch for GHSA-4hg4-9mf5-wxxq
What I did****How I did it****How to verify it****Commit message
Commit message for the final, squashed PR. (Optional, but reviewers will appreciate it! Please see our commit message style guide for what we would ideally like to see in a commit message.)
Description for the changelog****Cute Animal Picture
Related news
### Impact The order of evaluation of the arguments of the builtin functions `uint256_addmod`, `uint256_mulmod`, `ecadd` and `ecmul` does not follow source order. • For `uint256_addmod(a,b,c)` and `uint256_mulmod(a,b,c)`, the order is `c,a,b`. • For `ecadd(a,b)` and `ecmul(a,b)`, the order is `b,a`. Note that this behaviour is problematic when the evaluation of one of the arguments produces side effects that other arguments depend on. ### Patches https://github.com/vyperlang/vyper/pull/3583 ### Workarounds When using builtins from the list above, make sure that the arguments of the expression do not produce side effects or, if one does, that no other argument is dependent on those side effects. ### References _Are there any links users can visit to find out more?_