Open sherlock-admin2 opened 11 months ago
Escalate
This should be upgraded to high, breaks the core functionality of protocol, setting wrong status.
Escalate
This should be upgraded to high, breaks the core functionality of protocol, setting wrong status.
You've created a valid escalation!
To remove the escalation from consideration: Delete your comment.
You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.
To clarify impact, adding to @AhmadDecoded's escalation, since every new recipient after the initial registered recipient will have a currentStatus != Status.None
, we will continually update the status of the initial recipient, never actually correctly marking any recipient statuses. Since the registration process is used to determine distribution, in the worst case, following the on-chain registration statuses as expected to determine distribution, the pool manager may incorrectly distribute the full poolAmount solely to the initial registered recipient. In the best case, the pool will not be usable and a new one will have to be redeployed, causing the pool manager and any registered recipients to lose a material amount of funds due to gas costs every time a pool is created with this strategy.
To summarize, since the impact is either (perhaps unlikely) significant fund loss by believing contract state to be true or (100% likely) less significant gas loss due to the system completely failing every time, this should be classified as high severity.
Agree with Escalation that this is a high becasue of this impact described by @kadenzipfel,
in the worst case, following the on-chain registration statuses as expected to determine distribution, the pool manager may incorrectly distribute the full poolAmount solely to the initial registered recipient.
Planning to accept escalation and set severity to high
Result: High Has Duplicates
Why do the duplicates still have the Medium label?
Fixed. Note: recipientsCounter
is now +1 than the actual count of recipients.
GimelSec
high
recipientsCounter
should start from 1 inDonationVotingMerkleDistributionBaseStrategy
When doing
DonationVotingMerkleDistributionBaseStrategy._registerRecipient
, it checks the current status of the recipient. If the recipient is new to the pool, the status should beStatus.None
. However,recipientsCounter
starts from 0. The new recipient actually gets the status of first recipient of the pool.Vulnerability Detail
DonationVotingMerkleDistributionBaseStrategy._registerRecipient
calls_getUintRecipientStatus
to get the current status of the application. The status of the new application should beStatus.None
. Then, therecipientToStatusIndexes[recipientId]
torecipientsCounter
andrecipientsCounter
. https://github.com/sherlock-audit/2023-09-Gitcoin/blob/main/allo-v2/contracts/strategies/donation-voting-merkle-base/DonationVotingMerkleDistributionBaseStrategy.sol#L580DonationVotingMerkleDistributionBaseStrategy._getUintRecipientStatus
calls_getStatusRowColumn
to get the column index and current row. https://github.com/sherlock-audit/2023-09-Gitcoin/blob/main/allo-v2/contracts/strategies/donation-voting-merkle-base/DonationVotingMerkleDistributionBaseStrategy.sol#L819DonationVotingMerkleDistributionBaseStrategy._getStatusRowColumn
computes indexes fromrecipientToStatusIndexes[_recipientId]
. For the new recipient. Those indexes should be zero. https://github.com/sherlock-audit/2023-09-Gitcoin/blob/main/allo-v2/contracts/strategies/donation-voting-merkle-base/DonationVotingMerkleDistributionBaseStrategy.sol#L833The problem is that
recipientCounter
starts from zero. https://github.com/sherlock-audit/2023-09-Gitcoin/blob/main/allo-v2/contracts/strategies/donation-voting-merkle-base/DonationVotingMerkleDistributionBaseStrategy.sol#L166Consider the following situation:
registerRecipient
registerRecipient
.This implementation error makes the pool can only record the first application.
Impact
Code Snippet
https://github.com/sherlock-audit/2023-09-Gitcoin/blob/main/allo-v2/contracts/strategies/donation-voting-merkle-base/DonationVotingMerkleDistributionBaseStrategy.sol#L580 https://github.com/sherlock-audit/2023-09-Gitcoin/blob/main/allo-v2/contracts/strategies/donation-voting-merkle-base/DonationVotingMerkleDistributionBaseStrategy.sol#L819 https://github.com/sherlock-audit/2023-09-Gitcoin/blob/main/allo-v2/contracts/strategies/donation-voting-merkle-base/DonationVotingMerkleDistributionBaseStrategy.sol#L833 https://github.com/sherlock-audit/2023-09-Gitcoin/blob/main/allo-v2/contracts/strategies/donation-voting-merkle-base/DonationVotingMerkleDistributionBaseStrategy.sol#L166
Tool used
Manual Review
Recommendation
Make the counter start from 1. There are two methods to fix the issue.
1.
2.