Closed code423n4 closed 1 year ago
0xSorryNotSorry marked the issue as primary issue
yahgwai marked the issue as sponsor confirmed
yahgwai marked the issue as disagree with severity
Fix: https://github.com/ArbitrumFoundation/governance/pull/178 - updated docs for clarity Severity: Low, system working as intended. Votes cannot be cast at block.number anyway
0xean changed the severity to QA (Quality Assurance)
0xean marked the issue as grade-b
Lines of code
https://github.com/ArbitrumFoundation/governance/blob/c18de53820c505fc459f766c1b224810eaeaabc5/src/security-council-mgmt/governors/modules/SecurityCouncilMemberElectionGovernorCountingUpgradeable.sol#L232
Vulnerability details
Impact
The SecurityCouncilMemberElectionGovernorCountingUpgradeable:votesToWeight() helps to calculate the
votes weight
. The documentation says: 0 - 7 days. Votes cast will carry weight 1 per tokenThe problem is that the next validation is considering the
startBlock
as a zero vote weight:The
startBlock
number is considered a zero vote weight. Users can lost vote weight if they vote at thestartBlock
.Proof of Concept
SecurityCouncilMemberElectionGovernorCountingUpgradeable.sol#L232
Please see the next scenario:
blockNumber
is 9 and thestartBlock
is 10. ThevotesToWeight
calculation will be zero because9 <= 10 is True
.blockNumber
is 10 and thestartBlock
is 10. ThevotesToWeight
calculation will be zero because10 <= 10 is True
.The behaviour is wrong because the beginning of the voting period (startBlock) should be weight 1 per token.
Tools used
Manual review
Recommended Mitigation Steps
As the documentation says, the 0 day should be considered the weight 1 per token, therefore in the code the
startBlock
should not be considered as a weight zero:Assessed type
Invalid Validation