Submitted by nadin
https://github.com/GenerationSoftware/pt-v5-cgda-liquidator/blob/7f95bcacd4a566c2becb98d55c1886cadbaa8897/src/libraries/ContinuousGDA.sol#L34-L36
https://github.com/GenerationSoftware/pt-v5-cgda-liquidator/blob/7f95bcacd4a566c2becb98d55c1886cadbaa8897/src/libraries/ContinuousGDA.sol#L64
https://github.com/GenerationSoftware/pt-v5-cgda-liquidator/blob/7f95bcacd4a566c2becb98d55c1886cadbaa8897/src/libraries/ContinuousGDA.sol#L85-L87
https://github.com/PaulRBerg/prb-math/blob/5959ef59f906d689c2472ed08797872a1cc00644/src/sd59x18/Math.sol#L168-L181
ContinuousGDA.sol inherits a version of PRB Math that contains a vulnerability in the SD59x18.exp() function, which can be reverted on hugely negative numbers. SD59x18.exp() is used for calculations in ContinuousGDA.sol#purchasePrice() , ContinuousGDA.sol#purchaseAmount() and ContinuousGDA.sol#computeK(). Recently, the creators of the PRBMath have acknowledged this situation. Here is the corresponding link. This issue should be proactively corrected by PoolTogether to avoid unexpected results that corrupt the protocols computation flow.
There are 05 instances of this issue: see here
Proof of the bug acknowledgment by the creator of the PRBMath.
SD59x18.exp() correctly returns 0 for inputs less than (roughly) -41.45e18, however it starts to throw PRBMath_SD59x18_Exp2_InputTooBig when the input gets hugely negative. This is because of the unchecked multiplication in exp() overflowing into positive values: see here.
Manual Review and Proof of the bug acknowledgment by the creator of the PRBMath
A potential fix would be to compare the input with the smallest (most negative) number that can be safely multiplied by uLOG2_E, and return 0 if its smaller. Alternatively, exp() could return 0 for inputs smaller than -41.45e18, which are expected to be truncated to zero by exp2() anyway.
Math
asselstine (PoolTogether) confirmed
hickuphh3 (judge) commented:
