Function `getUserPastLock` may return incorrect values

[code423n4]

Lines of code

https://github.com/code-423n4/2022-03-paladin/blob/9c26ec8556298fb1dc3cf71f471aadad3a5c74a0/contracts/HolyPaladinToken.sol#L944-L958

Vulnerability details

Impact

userLocks array can contain elements with the same fromBlock properties, but different total locked amounts. This edge case is not considered in the implementation of getUserPastLock function, which returns a value as soon as it finds a UserLock with matching fromBlock property (see HolyPaladinToken.sol:949-951). If there are more user locks with the same block number, that function should return the latest one, i.e. the one with the highest index. In its current implementation getUserPastLock function can also return a different value after changing the length of the log, either from the correct value to an incorrect or the other way.

Not only does this bug ruin any external tools which rely on that function, but it also affects the return value of getPastVotes function. If user locks some amount and makes a call to increase it in the same block, getUserPastLock function may return an incorrect value and therefore getPastVotes will return to small amount of votes for that user.

Recommended mitigation steps

There are two obvious ways of fixing this issue: either by removing the check in HolyPaladinToken.sol:949-951)) or by not allowing adding elements to the userLocks array with the same fromBlock property. While both ways are viable, the latter one is preferred as it is a gas optimization. Checks should be added whether or not the block number of the last element of userLocks array is equal to the current block number, and if it is, modify that element instead of adding a new one.

[Kogaroshi]

Duplicate of https://github.com/code-423n4/2022-03-paladin-findings/issues/20 See in this issue for PR with changes

[0xean]

closing as dupe of #20