Lack of upperbound on iterated array rewardTokens in AuraLocker

[code423n4]

Lines of code

https://github.com/code-423n4/2022-05-aura/blob/4989a2077546a5394e3650bf3c224669a0f7e690/contracts/AuraLocker.sol#L195-L202

Vulnerability details

Impact

There is no upper bound on the size of the array rewardTokens in AuraLocker.

Since this array is iterated in multiple locations such as updateReward(), getReward(), claimableRewards() it is possible to end up in a state where there are too many reward tokens such that the contract cannot be iterated over them within the block gas limit.

The impact is that no rewards will be able to be withdrawn from the contract since the array rewardTokens is required to be iterated over in order to withdraw rewards.

This issue is rated Medium rather than High since addReward() which increases the size of this array is controlled via the DAO.

Proof of Concept

There are no restrictions on the number of tokens that can be pushed to rewardTokens in addReward().

    function addReward(address _rewardsToken, address _distributor) external onlyOwner {
        require(rewardData[_rewardsToken].lastUpdateTime == 0, "Reward already exists");
        require(_rewardsToken != address(stakingToken), "Cannot add StakingToken as reward");
        rewardTokens.push(_rewardsToken);
        rewardData[_rewardsToken].lastUpdateTime = uint32(block.timestamp);
        rewardData[_rewardsToken].periodFinish = uint32(block.timestamp);
        rewardDistributors[_rewardsToken][_distributor] = true;
    }

Recommended Mitigation Steps

Consider having a configurable upper bound that is set by the DAO to prevent accidental increase in the number of rewards tokens to a point where they cannot be iterated in the block gas limit.

[dmvt]

Downgrading to QA. While this is a valid report, the ability to add reward tokens is tightly controlled making this highly unlikely.