Impact
In versions 0.2.15, 0.2.16 and 0.3.0, named re-entrancy locks are allocated incorrectly. Each function using a named re-entrancy lock gets a unique lock regardless of the key, allowing cross-function re-entrancy in contracts compiled with the susceptible versions. A specific set of conditions is required to result in misbehavior of affected contracts, specifically:
- A
.vy contract compiled with either of the following vyper versions: 0.2.15, 0.2.16, 0.3.0
- A primary function that utilizes the
@nonreentrant decorator with a specific key and does not strictly follow the check-effects-interaction pattern (i.e. contains an external call to an untrusted party before storage updates)
- A secondary function that utilizes the same
key and would be affected by the improper state caused by the primary function
Patches
vyperlang/vyper#2439, vyperlang/vyper#2514
Workarounds
Upgrade to 0.3.1 or higher
References
Technical post-mortem report: https://hackmd.io/@vyperlang/HJUgNMhs2
References
Impact
In versions 0.2.15, 0.2.16 and 0.3.0, named re-entrancy locks are allocated incorrectly. Each function using a named re-entrancy lock gets a unique lock regardless of the key, allowing cross-function re-entrancy in contracts compiled with the susceptible versions. A specific set of conditions is required to result in misbehavior of affected contracts, specifically:
.vycontract compiled with either of the followingvyperversions:0.2.15,0.2.16,0.3.0@nonreentrantdecorator with a specifickeyand does not strictly follow the check-effects-interaction pattern (i.e. contains an external call to an untrusted party before storage updates)keyand would be affected by the improper state caused by the primary functionPatches
vyperlang/vyper#2439, vyperlang/vyper#2514
Workarounds
Upgrade to 0.3.1 or higher
References
Technical post-mortem report: https://hackmd.io/@vyperlang/HJUgNMhs2
References