_getReferencePoolPriceX96 will show incorrect price for negative ticks cause it doesn't round up for negative ticks.

[c4-bot-2]

Lines of code

https://github.com/code-423n4/2024-03-revert-lend/blob/435b054f9ad2404173f36f0f74a5096c894b12b7/src/V3Oracle.sol#L368-L375

Vulnerability details

Impact

Attacker will take advantage of inacurate prices returned for negative ticks.

Proof of Concept

The _getReferencePoolPriceX96 below does not take into account negative ticks.

            uint32[] memory secondsAgos = new uint32[](2);
            secondsAgos[0] = 0; // from (before)
            secondsAgos[1] = twapSeconds; // from (before)
            (int56[] memory tickCumulatives,) = pool.observe(secondsAgos); // pool observe may fail when there is not enough history available (only use pool with enough history!)
     @>     int24 tick = int24((tickCumulatives[0] - tickCumulatives[1]) / int56(uint56(twapSeconds))); //@note here can be negative 
            sqrtPriceX96 = TickMath.getSqrtRatioAtTick(tick);

This oversight poses a risk, especially when (tickCumulatives[1] - tickCumulatives[0]) % secondsAgo != 0, potentially resulting in a tick value that is larger than it should be. Such discrepancies can create opportunities for price manipulations and arbitrage.

To address this issue, it's crucial to ensure that negative tick values are properly handled and rounded down to avoid inaccuracies in determining the tick value. This correction will enhance the accuracy and reliability of the pricing mechanism, reducing the potential for exploitation and manipulation in the system.

Tools Used

Manual review

Recommended Mitigation Steps

Copy the uniswap implementation and add this line.

if (tickCumulatives[1] - tickCumulatives[0] < 0 && (tickCumulatives[1] - tickCumulatives[0]) % secondsAgo != 0) tick --;

Assessed type

Math

[c4-pre-sort]

0xEVom marked the issue as duplicate of #498

[c4-pre-sort]

0xEVom marked the issue as sufficient quality report

[c4-pre-sort]

0xEVom marked the issue as duplicate of #127

[c4-judge]

jhsagd76 marked the issue as satisfactory

[c4-judge]

jhsagd76 changed the severity to 3 (High Risk)