Full Report
Solana is a proof of stake network. So, the more value you provide in Solana, the more power you have in the voting process. With 2/3 of the control, changes to the state can be made. Clearly, ensuring that the staking and voting power is done properly is important. To stake funds, a user 1) creates an account 2) delegates the account) and 3) becomes activated. However, parsing all of the staked chain state every block would be incredibly inefficient. So, instead, a cache or running total is kept instead. If something relevant to the cache has changed then it makes an update to the cache. Solana allows active stake accounts to be merged. This will close one account and add the stakes to the other account without cooldown. When doing this, it does the detection by checking if the closed account has zero funds in it. Normally, this is the case, since the staking program address will do this. However, there is a logic bug here - it's possible to add funds to the old staking account so that it's not properly reaped. If this is done, then the key isn't removed from the cache! So, we can reuse the same staked values in multiple accounts by exploiting this logic flaw. To exploit, here are the steps: Create two staking accounts. Consolidate one account into the other. Add one lamport into the closed account. Solana core doesn't update the cache for the closed program because it has value. Recreate the vote account. The delegation is still there and the cache still doesn't get updated properly. To fix the vulnerability, the account is attempted to be deserialized instead of a zero funds check. Overall, a super interesting post on the desync between reality and the understanding of reality.
Analysis Summary