Potential Underflow via _modifyVote function in EthosVote Contract
Summary
A missing validation check for zero values in the EthosVote contract's _modifyVote function may cause an underflow when decrementing the upvotesCount or downvotesCount. This issue results in transaction reversion, disrupting users who attempt to modify their votes, and could lead to denial-of-service conditions for certain voting actions if not mitigated.
Root Cause
In the EthosVote: 188 contract, located in _modifyVote() function, underflows may occur because there are no checks to confirm that upvotesCount or downvotesCount are greater than zero before decrementing them.
Solidity version 0.8.26, which is used in this contract, includes automatic underflow protection, meaning that the transaction will revert if a decrement operation is performed on zero. However, such a reversion prevents the function from successfully executing.`
Internal pre-conditions
Vote Count: upvotesCount or downvotesCount for a specific target is 0.
User Action: The user calls voteFor() with the intention of modifying an existing vote.
Vote Status: The user's previous vote is active and not archived.
Vote Type: The new vote type (upvote or downvote) is opposite of the current vote.
External pre-conditions
External Function Call: voteFor() is called by a user.
This issue is self-contained within the contract.
Attack Path
A user casts a vote, incrementing either upvotesCount or downvotesCount.
The user archives their vote, decrementing the count back to 0.
The user attempts to re-cast the vote (with the same isUpvote or the opposite type).
The function attempts to decrement the count of an already-zero variable, causing an underflow and transaction reversion.
Impact
The affected users will experience failed transactions due to underflow reversion. This leads to:
Denial of Service: Users may not be able to modify or archive votes when the count is zero.
User Frustration: Users may incur additional gas costs due to failed transactions.
PoC
No response
Mitigation
Add Underflow Checks: In the _modifyVote() function, check that upvotesCount and downvotesCount are greater than zero before decrementing:
if (vote.isUpvote) {
require(vg.upvotesCount > 0, "Upvotes count cannot be less than zero");
vg.upvotesCount--;
} else {
require(vg.downvotesCount > 0, "Downvotes count cannot be less than zero");
vg.downvotesCount--;
}
0xmujahid002
High
Potential Underflow via
_modifyVote
function inEthosVote
ContractSummary
A missing validation check for zero values in the
EthosVote
contract's_modifyVote
function may cause an underflow when decrementing theupvotesCount
ordownvotesCount
. This issue results in transaction reversion, disrupting users who attempt to modify their votes, and could lead to denial-of-service conditions for certain voting actions if not mitigated.Root Cause
In the EthosVote: 188 contract, located in
_modifyVote()
function, underflows may occur because there are no checks to confirm thatupvotesCount
ordownvotesCount
are greater than zero before decrementing them. Solidity version 0.8.26, which is used in this contract, includes automatic underflow protection, meaning that the transaction will revert if a decrement operation is performed on zero. However, such a reversion prevents the function from successfully executing.`Internal pre-conditions
upvotesCount
ordownvotesCount
for a specific target is 0.voteFor()
with the intention of modifying an existing vote.External pre-conditions
voteFor()
is called by a user.Attack Path
upvotesCount
ordownvotesCount
.Impact
The affected users will experience failed transactions due to underflow reversion. This leads to:
PoC
No response
Mitigation
Add Underflow Checks: In the
_modifyVote()
function, check thatupvotesCount
anddownvotesCount
are greater than zero before decrementing: