code-423n4 / 2024-07-basin-validation

0 stars 0 forks source link

Incorrect Conditional Check for Decimals Leading to Incorrect Calculations #57

Closed c4-bot-6 closed 3 months ago

c4-bot-6 commented 3 months ago

Lines of code

https://github.com/code-423n4/2024-07-basin/blob/main/src/functions/Stable2.sol#L317

Vulnerability details

Impact

In the decodeWellData function where the conditional check incorrectly uses decimal0 instead of decimal1. This leads to returning incorrect decimals. The decodeWellData is used in almost all functions leads to incorrect calculations

Proof of Concept

In decodeWellData if well data returns 0,it assumes 18 , but the function checking decimal0 instead of decimal1 and assigning 18.


 // if well data returns 0, assume 18 decimals.
        if (decimal0 == 0) {
            decimal0 = 18;
        }
        if (decimal0 == 0) {
            decimal1 = 18;
        }

But in case of decimal1 = 0 and decimal0 != 0 , this check won't assign 18 to decimal1 which returns incorrect values.

Those returned values are used in getScaledReserves function which sets both reserves to 18 decimals. But in this case , it don't set the reserves to 18, this leads to incorrect calculation.

Tools Used

Manual Review

Recommended Mitigation Steps


 // if well data returns 0, assume 18 decimals.
        if (decimal0 == 0) {
            decimal0 = 18;
        }
        if (decimal1 == 0) { // change the variable name
            decimal1 = 18;
        }

Poc

edit this function in Stable2.t.sol and run .

function test_calcLpTokenSupply_diffDecimals() public {
        uint256[] memory reserves = new uint256[](2);
        _data = abi.encode(18, 0); // added 0 in place of 6
        reserves[0] = STATE_B_B0; // 10 USDT
        reserves[1] = STATE_B_B1; // 20 BEAN
        assertEq(_function.calcLpTokenSupply(reserves, _data), STATE_B_LP);
    }

This will revert

Assessed type

Invalid Validation