`mint(address to)` will revert after calling `_update` internally.

[code423n4]

Lines of code

https://github.com/Plex-Engineer/stableswap/blob/489d010eb99a0885139b2d5ed5a2d826838cc5f9/contracts/BaseV1-core.sol#L256 https://github.com/Plex-Engineer/stableswap/blob/489d010eb99a0885139b2d5ed5a2d826838cc5f9/contracts/BaseV1-core.sol#L192

Vulnerability details

Impact

Overflow is desired in the original version of UniswapV2 and it’s broken because of using Solidity version >0.8, which will impact and breakdown functionally of the BaseV1Pair and further breaks other parts of the blockchain that relies on.

Proof of Concept

Because of breaking changes in Solidity v0.8.0:

Arithmetic operations revert on underflow and overflow.

When overflow is desired will generate reverting problems with Solidity version > 0.8.0

• In BaseV1-core.sol when calling mint(address to) from BaseV1Pair contract will tray to update as oracle sender by calling _update() which has subtraction overflow is desired at blockTimestamp - blockTimestampLast

https://github.com/Plex-Engineer/stableswap/blob/489d010eb99a0885139b2d5ed5a2d826838cc5f9/contracts/BaseV1-core.sol#L156-L160

        uint timeElapsed = blockTimestamp - blockTimestampLast; // overflow is desired
        if (timeElapsed > 0 && _reserve0 != 0 && _reserve1 != 0) {
            reserve0CumulativeLast += _reserve0 * timeElapsed;
            reserve1CumulativeLast += _reserve1 * timeElapsed;
        }

• Also in currentCumulativePrices()

https://github.com/Plex-Engineer/stableswap/blob/489d010eb99a0885139b2d5ed5a2d826838cc5f9/contracts/BaseV1-core.sol#L181

if (_blockTimestampLast != blockTimestamp) {
            // subtraction overflow is desired
            uint timeElapsed = blockTimestamp - _blockTimestampLast;
            reserve0Cumulative += _reserve0 * timeElapsed;
            reserve1Cumulative += _reserve1 * timeElapsed;
}

Recommended Mitigation Steps

using unchecked {} code block

[GalloDaSballo]

I've run the math on this in another contest.

• blockTimestamp - blockTimestampLast this cannot reasonably underflow as currentTime >= lastBlock by definition

• reserve0Cumulative += _reserve0 * timeElapsed;

It would require Billion of Years, trading Quadrillion of ETH in volume each day to reach the requirement for overflow.

Because of that, I'm downgrading to QA