Chilly Wool Ladybug - An attacker can DOS addLvfSupportForPod for a given pod

[sherlock-admin4]

Chilly Wool Ladybug

Medium

An attacker can DOS addLvfSupportForPod for a given pod

Summary

Because of the use of create2, addLvfSupportForPod and createSelfLendingPodAndAddLvf can be front ran and allow an attacker to prevent the given pod to have the LVF functionality

Root Cause

Both addLvfSupportForPod( and createSelfLendingPodAndAddLvf( trigger the creation of the following oracle

_aspTknOracle = IAspTknOracleFactory(aspTknOracleFactory).create(
            _aspTkn, _aspTknOracleRequiredImmutables, _aspTknOracleOptionalImmutables, 0
        );

function create(address _aspTKN, bytes memory _requiredImmutables, bytes memory _optionalImmutables, uint96 _salt)
        external
        returns (address _oracleAddress)
    {
        _oracleAddress = _deploy(getBytecode(_aspTKN, _requiredImmutables, _optionalImmutables), _getFullSalt(_salt));
        aspTKNMinimalOracle(_oracleAddress).transferOwnership(owner());
        emit Create(_oracleAddress);
    }

...
function _deploy(bytes memory _bytecode, uint256 _finalSalt) internal returns (address _addr) {
        assembly {
            _addr := create2(callvalue(), add(_bytecode, 0x20), mload(_bytecode), _finalSalt)
            if iszero(_addr) { revert(0, 0) }//@audit can be front ran!
        }
    }

As you can see, the deployment of the oracle is made using create2, i.e is deterministic. This means an attacker can DOS the function by deploying that contract (at _addr) before the call is made.

Internal Pre-conditions

None

External Pre-conditions

None

Attack Path

An attacker can pre-compute the deployment of the oracle for a given pod(or do it so via front running, copying the parameters passed in addLvfSupportForPod), deploying before the call addLvfSupportForPod.

Impact

addLvfSupportForPod would simply revert because of the if iszero(_addr) { revert(0, 0) line. This means the LVF functionality cannot be added to that given pod, as per the comments in the code:

// this effectively is what "turns on" LVF for the pair
        ILeverageManagerAccessControl(leverageManager).setLendingPair(_pod, _fraxlendPair);

so leverage is never turned on for that pod, breaking an important functionality.

PoC

No response

Mitigation

No response