Summary
The buffer to start funding is defined as uint256 buffer = program.token.getBufferAmountByFlowRate(fundingFlowRate + subsidyFlowRate);.
However, due to the existence of the minimum deposit, whenever one of these rates multiplied by the liquidation period is smaller than the minimum buffer, the buffer needed will be underestimated and the program funding reverts as the resulting realtime balance of the FluidEPProgramManager is 0 after flowing (due to the wrong buffer).
This happens because it distributes 2 different flows (program + tax), so each one of them may require at least a minimum deposit. However, summed together (current estimate), they may require less than 2 minimum deposits (or only one of them would require a minimum deposit, but together with the other one, it would just increase the buffer by a smaller amount).
Root Cause
In FluidEPProgramManager:265, buffer is calculated as if it was 1 distributed flow, but due to the minimum deposit it is not the same.
Internal Pre-conditions
None.
External Pre-conditions
None.
Attack Path
- Admin calls
startFunding(), but one of the flow rates is too small and the total buffer required if the flow rate is approximated as one is smaller than the effective required buffer of distributing the 2 flows separately.
Impact
DoSed FluidEPProgramManager::startFunding(). Not only it is time sensitive, but also it won't allow the admin to start flows with all possible values, which is key functionality.
PoC
None.
Mitigation
Calculate the buffer individually for each flow rate.