You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When we compute the stake return at the beginning of the epoch, we assume that the accounts that need stake return exist, which, under normal circumstances make sense, but is not necessarily true when the return stake is 0. This creates a vector of attack as follows:
become a validator
stake 0
wait one epoch boundary
stake 1
wait 2 epoch boundaries until the account locked balance is 0
delete account
nodes will crash on next epoch boundary
Note: this critical vulnerability is reported by a third party partner (Thanks @kirk-baird).
The text was updated successfully, but these errors were encountered:
As described in #2687, there is a critical vulnerability caused by a situation where accounts are deleted after they unstake but we still try to return 0 stake to the account. This PR submits an easy fix to the issue by not requiring account to exist when the returned stake is no more than 0. Please note that this is not the optimal way to fix it. The better way would be to change epoch manager behavior so that it will only record accounts in `stake_change` if it is needed. In the case of unstaking, it means that a stake change should only be recorded if it is a change from nonzero (validator or fishermen) to zero. However, this PR is enough to quickly patch the issue so that we can spend more time ironing out the proper and better fix. Resolves#2687.
When we compute the stake return at the beginning of the epoch, we assume that the accounts that need stake return exist, which, under normal circumstances make sense, but is not necessarily true when the return stake is 0. This creates a vector of attack as follows:
Note: this critical vulnerability is reported by a third party partner (Thanks @kirk-baird).
The text was updated successfully, but these errors were encountered: