Lines of code
<https://github.com/code-423n4/2023-08-livepeer/blob/a3d801fa4690119b6f96aeb5508e58d752bda5bc/contracts/bonding/BondingManager.sol#L327&gt;
<https://github.com/code-423n4/2023-08-livepeer/blob/a3d801fa4690119b6f96aeb5508e58d752bda5bc/contracts/bonding/BondingManager.sol#L1519-L1520&gt;

Vulnerability details

Impact

If lastRewardRound >= currentRound, the earningsPool for currentRound may not be initialized if reward() has not yet been called for currentRound. So using it to update cumulative rewards or fees could be incorrect.
This can lead to incorrect reward calculations for delegators. For example, if the cumulativeRewardFactor is 0 when it should be non-zero, delegators will get 0 rewards.

Proof of Concept

The vulnerability occurs in pendingStakeAndFees() when _endRound = currentRound and lastRewardRound >= currentRound.

In this case, endEarningsPool will not be initialized because lastRewardRound >= currentRound. But then endEarningsPool is still used to calculate cumulative factors, even though it was never initialized. This could lead to using uninitialized (zero) cumulative factor values and incorrect reward calculations.

A proof of concept:

• Call updateTranscoderWithFees() in round 10
• This sets lastRewardRound = 10
• Call pendingStakeAndFees() in round 10, with _endRound = 10
• endEarningsPool = t.earningsPoolPerRound[10] is uninitialized because lastRewardRound (10) >= currentRound (10)
• pendingStakeAndFees still uses the uninitialized endEarningsPool for calculations

Tools Used

Manual

Recommended Mitigation Steps

A check in pendingStakeAndFees() to initialize endEarningsPool if lastRewardRound >= _endRound

Assessed type

Other

The text was updated successfully, but these errors were encountered:

All reactions