Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The `emergencyClose` function is designed to be a permanent and irreversible measure to repay all de. The `emergencyClose` function is designed to be a permanent and irreversible measure to repay all debts and shut down the vault, ensuring the finality and security of the vault's emergency closure process. This function is intended to be called by authorized parties, such as the Owner (Timelock + Mu...

Vulnerable code:
```\nFile: GMXVaul.sol\n\nfunction emergencyClose(uint256 deadline) external onlyOwner {\n    /**\n     * @notice Repays all debt owed by vault and shut down vault, allowing emergency withdrawals\n     * @dev Note that this is a one-way irreversible action\n     * @dev Should be called by approved Owner (Timelock + MultiSig)\n     */\n    GMXEmergency.emergencyClose(_store, deadline);\n}\n```\n```\nFile: GMXEmergency.sol\n\nfunction emergencyPause(\n    GMXTypes.Store storage self\n) external {\n    self.refundee = payable(msg.sender);\n\n    GMXTypes.RemoveLiquidityParams memory _rlp;\n\n    // Remove all of the vault's LP tokens\n    _rlp.lpAmt = self.lpToken.balanceOf(address(this));\n    _rlp.executionFee = msg.value;\n\n    GMXManager.removeLiquidity(\n        self,\n        _rlp\n    );\n\n    self.status = GMXTypes.Status.Paused;\n\n    emit EmergencyPause();\n}\n```\n```\nFile: GMXEmergency.sol\n\nfunction emergencyResume(\n    GMXTypes.Store storage self\n) external {\n    GMXChecks.beforeEmergencyResumeChecks(self);\n\n    self.status = GMXTypes.Status.Resume;\n\n    self.refundee = payable(msg.sender);\n\n    GMXTypes.AddLiquidityParams memory _alp;\n\n    _alp.tokenAAmt = self.tokenA.balanceOf(address(this));\n    _alp.tokenBAmt = self.tokenB.balanceOf(address(this));\n    _alp.executionFee = msg.value;\n\n    GMXManager.addLiquidity(\n        self,\n        _alp\n    );\n}\n```\n```\nfunction test_close_then_pause() external {\n    vault.emergencyPause();\n    console2.log("vault status", uint256(vault.store().status));\n\n    vault.emergencyClose(deadline);\n    console2.log("vault status", uint256(vault.store().status));\n\n    vault.emergencyPause();\n    console2.log("vault status", uint256(vault.store().status));\n    assertEq(uint256(vault.store().status), 10, "vault status not set to paused");\n\n    vault.emergencyResume();\n    console2.log("vault status", uint256(vault.store().status));\n}\n```
MEDIUM severity: The withdrawn ratios check in the contract, which compares the withdrawn ratios of OHM and wstETH ag. The withdrawn ratios check in the contract, which compares the withdrawn ratios of OHM and wstETH against the current oracle price, has the potential to inadvertently harm naive users. This occurs when the pool's LP is shifted towards wstETH, and the system takes any wstETH imbalances as a fee to th...

Vulnerable code:
```\nOHM token balance: 100_000\nwstETH token balance: 1_000\nTotal LP: 10_000\n```
MEDIUM severity: The `ECDSA` library, used in the `PaymentOutputToPaymentTxCondition` contract, fails to properly han. The `ECDSA` library, used in the `PaymentOutputToPaymentTxCondition` contract, fails to properly handle error values returned by the `recover` function. Specifically, when the input signature is malformed or the verification process fails, the `recover` function returns the address `0x00` or `addres...

Vulnerable code:
```\nif (uint256(s) > 0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0) {\n    return address(0);\n}\n\nif (v!= 27 && v!= 28) {\n    return address(0);\n}\n```\n```\naddress payable owner = inputTx.outputs[outputIndex].owner();\nrequire(owner == ECDSA.recover(eip712.hashTx(spendingTx), signature), "Tx is not signed correctly");\nreturn true;\n```
MEDIUM severity: The vulnerability is related to the inefficient gas usage when checking the maximum length of arrays. The vulnerability is related to the inefficient gas usage when checking the maximum length of arrays in certain scenarios. In the provided code, there are instances where arrays are limited to a specific number of items, and the maximum size is enforced by removing the last item if the array exceeds...

Vulnerable code:
```\nif (leaderboard.length == MAX_LEADERBOARD_SIZE + 1) {\n    leaderboard.pop();\n}\n```\n```\nif (topUsers.length == MAX_TOP_USERS_SIZE + 1) {\n    topUsers.pop();\n}\n```\n```\nif (_addresses.length == MAX_GROUP_LEADERS_SIZE.add(1)) {\n    groupsLeaders[_referralLink].pop();\n}\n```\n```\nif (limitedSizedArray.length > MAX_DEFINED_SIZE_FOR_ARRAY) {\n    limitedSizedArray.pop();\n}\n```
MEDIUM severity: The `_distribute()` function in the RFPSimpleStrategy contract contains a vulnerability that can lea. The `_distribute()` function in the RFPSimpleStrategy contract contains a vulnerability that can lead to a Denial of Service (DoS) attack. The function is responsible for distributing funds to a recipient based on their proposal bid and the milestone's amount percentage. However, the function has a...

Vulnerable code:
```\nfunction _distribute(\n    address[] memory _addresses,\n    bytes memory _bytes,\n    address _sender\n) \n    internal\n    virtual\n    override\n    onlyInactivePool\n    onlyPoolManager(_sender)\n{\n    IAllo.Pool memory pool = allo.getPool(poolId);\n    Milestone storage milestone = milestones[upcomingMilestone];\n    Recipient memory recipient = _recipients[acceptedRecipientId];\n\n    if (recipient.proposalBid > poolAmount) {\n        revert NOT_ENOUGH_FUNDS();\n    }\n\n    uint256 amount = (recipient.proposalBid * milestone.amountPercentage) / 1e18;\n\n    poolAmount -= amount; // NOTICE the poolAmount get decrease over time\n\n    _transferAmount(pool.token, recipient.recipientAddress, amount);\n}\n```\n```\nif (recipient.proposalBid > poolAmount) {\n    revert NOT_ENOUGH_FUNDS();\n}\n```
MEDIUM severity: The `deleverageAccount` function in `VaultAccountAction.sol` allows an address to bypass the `requir. The `deleverageAccount` function in `VaultAccountAction.sol` allows an address to bypass the `requireValidAccount` check in `enterVault`, which is designed to prevent system-level accounts from entering a vault. This check ensures that Notional system-level accounts are not allowed to enter a vault,...

Vulnerable code:
```\nrequire(account!= Constants.RESERVE); // Reserve address is address(0)\nrequire(account!= address(this));\n\n(\n    uint256 isNToken,\n    // incentiveAnnualEmissionRate,\n    // lastInitializedTime,\n    // assetArrayLength,\n    // parameters\n) = nTokenHandler.getNTokenContext(account);\nrequire(isNToken == 0);\n```
MEDIUM severity: The current system design lacks the capability to handle scenarios where native tokens with the same. The current system design lacks the capability to handle scenarios where native tokens with the same addresses, but different identities, exist on different layers. This limitation can lead to incorrect bridging outcomes.\n\nFor instance, consider a situation where a native token `A` has already bee...

Vulnerable code:
```\nmapping(address => address) public nativeToBridgedToken;\nmapping(address => address) public bridgedToNativeToken;\n```\n```\nfunction completeBridging(\n    address _nativeToken,\n    uint256 _amount,\n    address _recipient,\n    bytes calldata _tokenMetadata\n) external onlyMessagingService fromRemoteTokenBridge {\n    address nativeMappingValue = nativeToBridgedToken[_nativeToken];\n    address bridgedToken;\n\n    if (nativeMappingValue == NATIVE_STATUS) {\n        IERC20(_nativeToken).safeTransfer(_recipient, _amount);\n    } else {\n        // Add your code here\n    }\n}\n```
MEDIUM severity: The auction mechanism is designed to accommodate bids within a specified `timeBuffer` period at the . The auction mechanism is designed to accommodate bids within a specified `timeBuffer` period at the end of a max duration auction, extending the remaining duration to `timeBuffer` if a bid is received. However, a critical error in the `createBid()` function in AuctionHouse.sol causes all bids within...

Vulnerable code:
```\nif (firstBidTime + duration - block.timestamp < timeBuffer)\n```\n```\nuint64 newDuration = uint256(duration + (block.timestamp + timeBuffer - firstBidTime)).safeCastTo64();\n```\n```\nauctions[tokenId].duration = auctions[tokenId].maxDuration - firstBidTime\n```
MEDIUM severity: The system's design allows for unpredictable behavior due to the lack of safeguards against administ. The system's design allows for unpredictable behavior due to the lack of safeguards against administrative actions that may compromise the security goals of the system. Specifically, administrators with privileged roles can make changes to the system without warning, which may lead to malicious or u...

Vulnerable code:
```\nfunction setOperatorFee(uint256 _operatorFee) external onlyAdmin {\n    if (_operatorFee > StakingContractStorageLib.getOperatorCommissionLimit()) {\n        revert InvalidFee();\n    }\n    StakingContractStorageLib.setOperatorFee(_operatorFee);\n    emit ChangedOperatorFee(_operatorFee);\n}\n```\n```\nfunction setGlobalFee(uint256 _globalFee) external onlyAdmin {\n    if (_globalFee > StakingContractStorageLib.getGlobalCommissionLimit()) {\n        revert InvalidFee();\n    }\n    StakingContractStorageLib.setGlobalFee(_globalFee);\n    emit ChangedGlobalFee(_globalFee);\n}\n```
MEDIUM severity: The `settingNameSpace` variable in the `RocketDAONodeTrustedSettings` and `RocketDAOProtocolSettings. The `settingNameSpace` variable in the `RocketDAONodeTrustedSettings` and `RocketDAOProtocolSettings` contracts is currently mutable, allowing it to be modified after the contract's deployment. This is a potential security vulnerability, as it could be exploited by an attacker to manipulate the sett...

Vulnerable code:
```\nbytes32 settingNameSpace;\n```\n```\nconstructor(RocketStorageInterface _rocketStorageAddress, string memory _settingNameSpace) RocketBase(_rocketStorageAddress) {\n    settingNameSpace = keccak256(abi.encodePacked("dao.trustednodes.setting.", _settingNameSpace));\n}\n```\n```\nbytes32 settingNameSpace;\n```\n```\nconstructor(RocketStorageInterface _rocketStorageAddress, string memory _settingNameSpace) RocketBase(_rocketStorageAddress) {\n    settingNameSpace = keccak256(abi.encodePacked("dao.protocol.setting.", _settingNameSpace));\n}\n```\n```\nconstructor(RocketStorageInterface _rocketStorageAddress) {\n    RocketDAOProtocolSettings(_rocketStorageAddress, "auction") {\n        // Set version\n        version = 1;\n    }\n}\n```
MEDIUM severity: The `prepareVacancy` function in the `RocketMinipoolDelegate` contract is responsible for updating t. The `prepareVacancy` function in the `RocketMinipoolDelegate` contract is responsible for updating the contract's state variables when a node operator sets a bond value and vacancy flag. This function is a critical part of the minipool's lifecycle, as it determines the node's status and calculates t...

Vulnerable code:
```\nfunction prepareVacancy(uint256 _bondAmount, uint256 _currentBalance) override external onlyLatestContract("rocketMinipoolManager", msg.sender) onlyInitialised {\n    require(status == MinipoolStatus.Initialised, "Must be in initialised status");\n    require(nodeRefundBalance == 0, "Refund balance not zero");\n\n    RocketDAOProtocolSettingsMinipoolInterface rocketDAOProtocolSettingsMinipool = \n        RocketDAOProtocolSettingsMinipoolInterface(getContractAddress("rocketDAOProtocolSettingsMinipool"));\n    uint256 launchAmount = rocketDAOProtocolSettingsMinipool.getLaunchBalance();\n    require(_currentBalance >= launchAmount, "Balance is too low");\n\n    nodeDepositBalance = _bondAmount;\n    userDepositBalance = launchAmount.sub(nodeDepositBalance);\n    vacant = true;\n    preMigrationBalance = _currentBalance;\n    nodeRefundBalance = _currentBalance.sub(launchAmount);\n    setStatus(MinipoolStatus.Prelaunch);\n}\n```
MEDIUM severity: The `Goldilend.repay()` function, responsible for processing loan repayments, contains a critical er. The `Goldilend.repay()` function, responsible for processing loan repayments, contains a critical error in its logic for updating the `poolSize` variable. Specifically, when a user repays their loan, the function increments `poolSize` by multiplying `userLoan.interest` with a ratio, which is incorre...

Vulnerable code:
```\nfunction repay(uint256 repayAmount, uint256 _userLoanId) external {\n    Loan memory userLoan = loans[msg.sender][_userLoanId];\n    if (userLoan.borrowedAmount < repayAmount) {\n        revert ExcessiveRepay();\n    }\n    if (block.timestamp > userLoan.endDate) {\n        revert LoanExpired();\n    }\n    uint256 interestLoanRatio = FixedPointMathLib.divWad(userLoan.interest, userLoan.borrowedAmount);\n    uint256 interest = FixedPointMathLib.mulWadUp(repayAmount, interestLoanRatio);\n    outstandingDebt -= repayAmount - interest > outstandingDebt? outstandingDebt : repayAmount - interest;\n    loans[msg.sender][_userLoanId].borrowedAmount -= repayAmount;\n    loans[msg.sender][_userLoanId].interest -= interest;\n    poolSize += userLoan.interest * (1000 - (multisigShare + apdaoShare)) / 1000;\n}\n```
MEDIUM severity: The `actionChallengeDecide` function in the RocketDAO node emits an ambiguous event, `challengeSucce. The `actionChallengeDecide` function in the RocketDAO node emits an ambiguous event, `challengeSuccess=False`, in two scenarios: when the challenged node defeats the challenge and when another node calls `actionChallengeDecide` before the refute window has passed. This ambiguity can lead to a situat...

Vulnerable code:
```\nfunction handleChallengeRefute(address _nodeAddress, bytes32 msg) public {\n    // Allow the challenged member to refute the challenge at anytime. If the window has passed and the challenge node does not run this method, any member can decide the challenge and eject the absent member\n    if (_nodeAddress == msg.sender) {\n        // Challenge is defeated, node has responded\n        deleteUint(keccak256(abi.encodePacked(daoNameSpace, "member.challenged.block", _nodeAddress)));\n    } else {\n        // The challenge refute window has passed, the member can be ejected now\n        if (getUint(keccak256(abi.encodePacked(daoNameSpace, "member.challenged.block", _nodeAddress))).add(rocketDAONodeTrustedSettingsMembers.getChallengeWindow()) < block.number) {\n            // Node has been challenged and failed to respond in the given window, remove them as a member and their bond is burned\n            _memberRemove(_nodeAddress);\n            // Challenge was successful\n            challengeSuccess = true;\n        }\n    }\n    // Log it\n    emit ActionChallengeDecided(_nodeAddress, msg.sender, challengeSuccess, block.timestamp);\n}\n```
MEDIUM severity: The `settle` function in the `Vault` contract is vulnerable to an unexpected behavior when settling . The `settle` function in the `Vault` contract is vulnerable to an unexpected behavior when settling the 0 address. This occurs due to the way the `context.global` and `context.local` variables are initialized in the `_loadContext` function.\n\nIn the `_loadContext` function, `context.global` is set...

Vulnerable code:
```\nfunction _loadContext(address account) private view returns (Context memory context) {\n    context.global = _accounts[address(0)].read();\n    context.local = _accounts[account].read();\n    context.latestCheckpoint = _checkpoints[context.global.latest].read();\n}\n```\n```\nfunction _settle(Context memory context) private {\n    // settle global positions\n    while (\n        context.global.current > context.global.latest &&\n        _mappings[context.global.latest + 1].read().ready(context.latestIds)\n    ) {\n        uint256 newLatestId = context.global.latest + 1;\n        context.latestCheckpoint = _checkpoints[newLatestId].read();\n        (\n            Fixed6 collateralAtId,\n            UFixed6 feeAtId,\n            UFixed6 keeperAtId\n        ) = _collateralAtId(context, newLatestId);\n        context.latestCheckpoint.complete(\n            collateralAtId,\n            feeAtId,\n            keeperAtId\n        );\n        context.global.processGlobal(\n            newLatestId,\n            context.latestCheckpoint,\n            context.latestCheckpoint.deposit,\n            context.latestCheckpoint.redemption\n        );\n        _checkpoints[newLatestId].store(context.latestCheckpoint);\n    }\n\n    // settle local position\n    if (\n        context.local.current > context.local.latest &&\n        _mappings[context.local.current].read().ready(context.latestIds)\n    ) {\n        uint256 newLatestId = context.local.current;\n        Checkpoint memory checkpoint = _checkpoints[newLatestId].read();\n        context.local.processLocal(\n            newLatestId,\n            checkpoint,\n            context.local.deposit,\n            context.local.redemption\n        );\n    }\n}\n```
MEDIUM severity: The vulnerability arises from a mathematical error in the calculation of the vault fee for strategis. The vulnerability arises from a mathematical error in the calculation of the vault fee for strategists. The intended logic is to set the vault fee in basis points (BPS) as a fraction of the total amount being paid, and then convert this amount into shares to be added to the strategist's unclaimed sh...

Vulnerable code:
```\nfunction _handleStrategistInterestReward(uint256 lienId, uint256 amount)\n    internal\n    virtual\n    override\n{\n    if (VAULT_FEE()!= uint256(0)) {\n        uint256 interestOwing = LIEN_TOKEN().getInterest(lienId);\n        uint256 x = (amount > interestOwing)? interestOwing : amount;\n        uint256 fee = x.mulDivDown(VAULT_FEE(), 1000);\n        strategistUnclaimedShares += convertToShares(fee);\n    }\n}\n```
MEDIUM severity: The UniProxy.depositSwap function in the UniProxy contract is vulnerable to a potential fund loss is. The UniProxy.depositSwap function in the UniProxy contract is vulnerable to a potential fund loss issue. When executing a swap, the function passes the minimum amount out (`deposit1`) to the router, but the actual swap amount is stored in the `amountOut` variable. However, after the trade, the contr...

Vulnerable code:
```\nelse {\n    swap = uint256(swapAmount);\n    IHypervisor(pos).token0().transferFrom(msg.sender, address(this), deposit0 + swap);\n\n    amountOut = router.exactInput(\n        ISwapRouter.ExactInputParams(\n            path,\n            address(this),\n            block.timestamp + swapLife,\n            swap,\n            deposit1\n        )\n    );\n\n    require(amountOut > 0, "Swap failed");\n\n    if (positions[pos].version < 2) {\n        shares = IHypervisor(pos).deposit(deposit0, deposit1, address(this));\n        IHypervisor(pos).transfer(to, shares);\n    }\n}\n```
MEDIUM severity: The `buyCollateral()` function in the `BBLeverage` contract is not functioning as intended. This fun. The `buyCollateral()` function in the `BBLeverage` contract is not functioning as intended. This function is responsible for buying collateral from the `yieldBox` contract and executing the `addCollateral()` function. However, the implementation contains several critical issues that can lead to unex...

Vulnerable code:
```\nfunction buyCollateral(address from, uint256 borrowAmount, uint256 supplyAmount, bytes calldata data)\n    external\n    optionNotPaused(PauseType.LeverageBuy)\n    solvent(from, false)\n    notSelf(from)\n    returns (uint256 amountOut)\n{\n    if (address(leverageExecutor) == address(0)) {\n        revert LeverageExecutorNotValid();\n    }\n\n    // Stack too deep fix\n    _BuyCollateralCalldata memory calldata_;\n    _BuyCollateralMemoryData memory memoryData;\n\n    {\n        calldata_.from = from;\n        calldata_.borrowAmount = borrowAmount;\n        calldata_.supplyAmount = supplyAmount;\n        calldata_.data = data;\n    }\n\n    {\n        uint256 supplyShare = yieldBox.toShare(assetId, calldata_.supplyAmount, true);\n        if (supplyShare > 0) {\n            (memoryData.supplyShareToAmount, ) =\n                yieldBox.withdraw(assetId, calldata_.from, address(leverageExecutor), 0, supplyShare);\n        }\n    }\n\n    {\n        (, uint256 borrowShare) = _borrow(\n            calldata_.from,\n            address(this),\n            calldata_.borrowAmount,\n            _computeVariableOpeningFee(calldata_.borrowAmount)\n        );\n        (memoryData.borrowShareToAmount, ) =\n            yieldBox.withdraw(assetId, address(this), address(leverageExecutor), 0, borrowShare);\n    }\n\n    {\n        amountOut = leverageExecutor.getCollateral(\n            collateralId,\n            address(asset),\n            address(collateral),\n            memoryData.supplyShareToAmount + memoryData.borrowShareToAmount,\n            calldata_.from,\n            calldata_.data\n        );\n    }\n\n    uint256 collateralShare = yieldBox.toShare(collateralId, amountOut, false);\n    address(asset).safeApprove(address(yieldBox), type(uint256).max);\n    yieldBox.depositAsset(collateralId, address(this), address(this), 0, collateralShare);\n    address(asset).safeApprove(address(yieldBox), 0);\n\n    if (collateralShare == 0) {\n        revert CollateralShareNotValid();\n    }\n\n    _allowedBorrow(calldata_.from, collateralShare);\n    _addCollateral(calldata_.from, calldata_.from, false, 0, collateralShare);\n}\n```
MEDIUM severity: The `_estimateWithdrawalLp` function in the Dispatcher contract calculates the estimated withdrawal . The `_estimateWithdrawalLp` function in the Dispatcher contract calculates the estimated withdrawal amount based on the average of the ratios `amount0 / reserve0` and `amount1 / reserve1`. This calculation is used to determine the amount of Multipool LP tokens that a user can withdraw from the contr...

Vulnerable code:
```\nfunction _estimateWithdrawalLp(\n    uint256 reserve0,\n    uint256 reserve1,\n    uint256 _totalSupply,\n    uint256 amount0,\n    uint256 amount1\n) private pure returns (uint256 shareAmount) {\n    shareAmount = (\n        (amount0 * _totalSupply) / reserve0 +\n        (amount1 * _totalSupply) / reserve1\n    ) / 2;\n}\n```\n```\nuint256 lpAmount;\n\n(uint256 fee0, uint256 fee1) = _calcFees(feesGrow, user);\n\nlpAmount = _estimateWithdrawalLp(reserve0, reserve1, _totalSupply, fee0, fee1);\n\nuser.shares -= lpAmount;\n\n_withdrawFee(pool, lpAmount, reserve0, reserve1, _totalSupply, deviationBP);\n```
MEDIUM severity: The `resistantBalanceAndFei` function in the `StableSwapOperatorV1` contract is responsible for calc. The `resistantBalanceAndFei` function in the `StableSwapOperatorV1` contract is responsible for calculating the amount of funds controlled by the protocol and the number of FEI tokens temporarily minted. These FEI tokens are not backed by collateral and should not be used in calculations determining...

Vulnerable code:
```\nuint256 _3crvAmount, uint256 _feiAmount = (\n    IStableSwap2(pool).balances(_3crvIndex),\n    IStableSwap2(pool).balances(_feiIndex)\n);\n\nuint256 _3crvAmountAfter = _3crvAmount + _3crvBalanceAfter;\n\nuint256 _3crvUsdValue = _3crvAmountAfter * IStableSwap3(_3pool).get_virtual_price() / 1e18;\n\nuint256 _feiToDeposit = 0;\nif (_3crvUsdValue > _feiAmount) {\n    _feiToDeposit = _3crvUsdValue - _feiAmount;\n}\n```\n```\nuint256[2] memory _minAmounts; // [0, 0]\n\nIERC20(pool).approve(pool, _lpToWithdraw);\n\nuint256 _3crvBalanceBefore = IERC20(_3crv).balanceOf(address(this));\n\nIStableSwap2(pool).remove_liquidity(_lpToWithdraw, _minAmounts);\n```\n```\nresistantBalance = _lpPriceUSD / 2;\nresistantFei = resistantBalance;\n```