we set lastVoted to the start of the current epoch
the problem rises from the fact that users unintentially may vote for killed Gauges without knowing that they are killed and in _vote there is no check for reverts for current scenario
function _vote(uint256 _tokenId, address[] memory _poolVote, uint256[] memory _weights) internal {
...... SKIP
for (uint i = 0; i < _poolCnt; i++) {
if (isAlive[gauges[_poolVote[i]]]) _totalVoteWeight += _weights[i];
}
for (uint256 i = 0; i < _poolCnt; i++) {
address _pool = _poolVote[i];
address _gauge = gauges[_pool];
if (isGauge[_gauge] && isAlive[_gauge]) {
...... SKIP
require(votes[_tokenId][_pool] == 0);
require(_poolWeight != 0);
...... SKIP
}
}
if (_usedWeight > 0) IVotingEscrow(_ve).voting(_tokenId);
totalWeightsPerEpoch[_time] += _totalWeight;
}
as we see checks and potential reverts are inside the if (isGauge[_gauge] && isAlive[_gauge]) of the loop
and this if statement won't come to be true
then this will lead to txn bein executed with no revert and the lastVoted[_tokenId] = _epochTimestamp() + 1; would be set in vote with no problems
now during the _voteDelay check, this will always revert and will lead to user losing the rewards of the current epoch
Attack Scenario\
User see see good Gauges and vote for them in epochs and get good rewards in epoch 1
Governance kills the Gauges
User's voting balance increase and he wants to increse his votes in the gauag -> votes for the killed Gauges in epoch 2
Txn executes and doesn't revert
User will get no rewards for the epoch 2 if VOTE_DELAY == MAX_VOTE_DELAY or MAX_VOTE_DELAY - 1
Github username: -- Twitter username: ililhunterlili Submission hash (on-chain): 0x2abf270b24997b728ee03c9597b032a82888702290ef262f27e2d1709e505856 Severity: medium
Description: Description\
first of all we have to take into considerations that
VOTE_DELAY
can be atMAX_VOTE_DELAY
due to this checktaking into considerations that
VOTE_DELAY
may be actually 1 Week then we see that atwe set
lastVoted
to the start of the current epochthe problem rises from the fact that users unintentially may vote for killed
Gauges
without knowing that they are killed and in_vote
there is no check for reverts for current scenarioas we see checks and potential reverts are inside the
if (isGauge[_gauge] && isAlive[_gauge])
of the loop and thisif
statement won't come to be truethen this will lead to txn bein executed with no revert and the
lastVoted[_tokenId] = _epochTimestamp() + 1;
would be set invote
with no problemsnow during the
_voteDelay
check, this will always revert and will lead to user losing the rewards of the current epochAttack Scenario\
Governance
kills the GaugesVOTE_DELAY
==MAX_VOTE_DELAY
orMAX_VOTE_DELAY
- 1Attachments
Proof of Concept (PoC) File
Revised Code File (Optional)