Submitted by Trust, also found by AgileJune, Bigsam, and grearlake
The LockingMultiRewards contract facilitates distribution of rewards across the remaining epoch duration. The calculation for reward rate is provided below:
reward.rewardRate = amount / _remainingRewardTime;
The rate is later multiplied by the  duration to get the total rewards for elapsed time, demonstrated below:
An issue occurs because there is no sufficient wrapping of the amount before dividing by _remainingRewardTime. The number is divided and later multiplied by elapsed time, causing a loss of precision of the amount modulo remaining time. For the provided period of 1 week by the sponsor, the maximum amount lost can be calculated:
7 * 24 * 3600 - 1 = 604799.
Note that the average case loss is half of the worst case assuming even distribution across time. However since rewards are usually not sent at the low end of remaining time (see the minRemainingTime variable, the actual average would be higher).
The effect of this size of loss depends on the decimals and value of the reward token. For USDC, this would be $0.6. For WBTC,  it would be$423 (at time of writing). The loss is shared between all stakers relative to their stake amount. The loss occurs for every notification, so it is clear losses will be severe.
Sponsor remarked in the channel that reward tokens would be real, popular tokens. We believe USDC / WBTC on ARB are extremely popular tokens and therefore remain fully in scope as reward tokens.
Impact - high
Likelihood - medium
-> Severity - high
Permanent loss of yield for stakers in reward pools due to precision loss.
Store the rewardRate scaled by 1e18, so loss of precision will be lower by magnitude of 1e18.
0xCalibur (Abracadabra) disputed and commented via duplicate #166:
Trust (Warden) commented:
