Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The `_fundPool` function in the smart contract is vulnerable to an issue when interacting with fee-o. The `_fundPool` function in the smart contract is vulnerable to an issue when interacting with fee-on-transfer tokens. Specifically, the `increasePoolAmount` parameter is directly used in the `transferFrom` call without considering the fee associated with the transfer.\n\nWhen a fee-on-transfer toke...

Vulnerable code:
```\n_transferAmountFrom(_token, TransferData({\n    from: msg.sender,\n    to: address(_strategy),\n    amount: amountAfterFee\n});\n\n_strategy.increasePoolAmount(amountAfterFee);\n```
MEDIUM severity: The `TokenSaleProposal::buy` function, which is responsible for facilitating the purchase of DAO tok. The `TokenSaleProposal::buy` function, which is responsible for facilitating the purchase of DAO tokens using a pre-approved token, contains a critical flaw. Specifically, it implicitly assumes that the `amount` of the ERC20 token being transferred is always 18 decimals, without performing any neces...

Vulnerable code:
```\nfunction _sendFunds(address token, address to, uint256 amount) internal {\n    if (token == ETHEREUM_ADDRESS) {\n        (bool success, ) = to.call{value: amount}("");\n        require(success, "TSP: failed to transfer ether");\n    } else {\n        IERC20(token).safeTransferFrom(msg.sender, to, amount);\n    }\n}\n```
MEDIUM severity: The Curve V2 Vaults are vulnerable to reentrancy attacks due to the CurveV2CryptoEthOracle's failure. The Curve V2 Vaults are vulnerable to reentrancy attacks due to the CurveV2CryptoEthOracle's failure to properly validate the `checkReentrancy` parameter. Specifically, the `registerPool` function does not correctly verify that the pool contains only ETH tokens, allowing WETH tokens to be used inste...

Vulnerable code:
```\naddress public constant ETH = 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE;\n\npublic function someFunction() {\n    // rest of code\n\n    // Only need ability to check for read-only reentrancy for pools containing native Eth.\n    if (checkReentrancy) {\n        if (tokens[0]!= ETH && tokens[1]!= ETH) {\n            revert MustHaveEthForReentrancy();\n        }\n    }\n}\n```\n```\ndef exchange(i: uint256, j: uint256, dx: uint256, min_dy: uint256, use_eth: bool = False) -> uint256:\n    pass\n\ndef add_liquidity(amounts: uint256[3], min_mint_amount: uint256, use_eth: bool = False) -> uint256:\n    pass\n\ndef remove_liquidity(_amount: uint256, min_amounts: uint256[3], use_eth: bool = False):\n    pass\n\ndef remove_liquidity_one_coin(token_amount: uint256, i: uint256, min_amount: uint256, use_eth: bool = False) -> uint256:\n    pass\n```\n```\nif (poolInfo.checkReentrancy == 1):\n    cryptoPool.claim_admin_fees()\n```
MEDIUM severity: The `Cooler.roll()` function is designed to extend the loan duration by transferring additional coll. The `Cooler.roll()` function is designed to extend the loan duration by transferring additional collateral to the contract. However, when the `newCollateral` amount is set to 0, the function's behavior becomes unpredictable. This is because the `collateral.transferFrom()` call, which is responsible...

Vulnerable code:
```\nfunction roll(uint256 loanID) external {\n    Loan storage loan = loans[loanID];\n    Request memory req = loan.request;\n\n    if (block.timestamp > loan.expiry) {\n        revert Default();\n    }\n\n    if (!loan.rollable) {\n        revert NotRollable();\n    }\n\n    uint256 newCollateral = collateralFor(loan.amount, req.loanToCollateral) - loan.collateral;\n    uint256 newDebt = interestFor(loan.amount, req.interest, req.duration);\n\n    loan.amount += newDebt;\n    loan.expiry += req.duration;\n    loan.collateral += newCollateral;\n\n    collateral.transferFrom(msg.sender, address(this), newCollateral);\n}\n```
MEDIUM severity: The `Hypervisor` contract is susceptible to multiple "sandwiching" front-running vectors due to its . The `Hypervisor` contract is susceptible to multiple "sandwiching" front-running vectors due to its decentralized nature, allowing malicious actors to manipulate the order of transactions. Specifically, the `pool.swap`, `pool.mint`, and `pool.burn` functions can be exploited by a potential "sandwich...

Vulnerable code:
```\nif (swapQuantity!= 0) {\n    pool.swap(\n        address(this),\n        swapQuantity > 0,\n        swapQuantity > 0? swapQuantity : -swapQuantity,\n        swapQuantity > 0? TickMath.MIN_SQRT_RATIO + 1 : TickMath.MAX_SQRT_RATIO - 1,\n        abi.encode(address(this))\n    );\n}\n```\n```\nfunction _mintLiquidity(\n    int24 tickLower,\n    int24 tickUpper,\n    uint128 liquidity,\n    address payer\n) internal returns (uint256 amount0, uint256 amount1) {\n    if (liquidity > 0) {\n        (amount0, amount1) = pool.mint(\n            address(this),\n            tickLower,\n            tickUpper,\n            liquidity,\n            abi.encode(payer)\n        );\n    }\n}\n```\n```\nfunction _burnLiquidity(\n    int24 tickLower,\n    int24 tickUpper,\n    uint128 liquidity,\n    address to,\n    bool collectAll\n) internal returns (uint256 amount0, uint256 amount1) {\n    if (liquidity > 0) {\n        uint256 owed0, uint256 owed1 = pool.burn(tickLower, tickUpper, liquidity);\n\n        uint128 collect0 = collectAll? type(uint128).max : uint128(owed0);\n        uint128 collect1 = collectAll? type(uint128).max : uint128(owed1);\n        if (collect0 > 0 || collect1 > 0) {\n            (amount0, amount1) = pool.collect(to, tickLower, tickUpper, collect0, collect1);\n        }\n    }\n}\n```
MEDIUM severity: The `_ragequit` function iterates over a list of whitelisted tokens, attempting to distribute a port. The `_ragequit` function iterates over a list of whitelisted tokens, attempting to distribute a portion of the tokens among users. However, this process is vulnerable to a gas exhaustion attack, which can occur when the number of tokens exceeds a certain threshold. This threshold is approximately 30...

Vulnerable code:
```\nfor (uint256 i = 0; i < tokens.length; i++) {\n    uint256 amountToRagequit = fairShare(userTokenBalances[GUILD][tokens[i]], sharesAndLootToBurn, initialTotalSharesAndLoot);\n    userTokenBalances[GUILD][tokens[i]] -= amountToRagequit;\n    userTokenBalances[memberAddress][tokens[i]] += amountToRagequit;\n}\n```
MEDIUM severity: The `BlueBerryBank` contract's `getPositionValue` function is vulnerable to a Denial-of-Service (DoS. The `BlueBerryBank` contract's `getPositionValue` function is vulnerable to a Denial-of-Service (DoS) attack when a reward token is added to a pool without an associated oracle. This occurs when the `pendingRewards` method is called, which retrieves a fresh list of tokens from the `Aura/Convex` cont...

Vulnerable code:
```\nERC20Wrapper(address[] memory tokens, uint256[] memory rewards) = IERC20Wrapper(\n    pos.collToken\n).pendingRewards(pos.collId, pos.collateralSize);\nfor (uint256 i; i < tokens.length; i++) {\n    rewardsValue += oracle.getTokenValue(tokens[i], rewards[i]);\n}\n```
MEDIUM severity: The protocol's assumption of fully hedging traders' profits by re-balancing the vault between base a. The protocol's assumption of fully hedging traders' profits by re-balancing the vault between base and side tokens after each trade is broken when trading out-of-the-money options. Specifically, options with a delta of 0, such as IG Bull when the current asset price is below the strike or IG Bear wh...

Vulnerable code:
```\n/**\n    Δ_bull = (1 / θ) * F\n    F = \n        * 0                     if (S < K)\n        * (1 - √(K / Kb)) / K   if (S > Kb)\n        * 1 / K - 1 / √(S * K)  if (K < S < Kb)\n    */\n\nfunction bullDelta(uint256 k, uint256 kB, uint256 s, uint256 theta) internal pure returns (int256) {\n    SD59x18 delta;\n    if (s <= k) {\n        return 0;\n    }\n```
MEDIUM severity: The `updateYield` function in the `LibVault` library is responsible for updating the vault's yield r. The `updateYield` function in the `LibVault` library is responsible for updating the vault's yield rate from staking rewards earned by bridge contracts holding LSD. This function is called by the permissionless `YieldFacet.updateYield` function, which allows anyone to update the vault's yield rate....

Vulnerable code:
```\nfunction updateYield(uint256 vault) internal {\n    AppStorage storage s = appStorage();\n    STypes.Vault storage Vault = s.vault[vault];\n    STypes.VaultUser storage TAPP = s.vaultUser[vault][address(this)];\n\n    uint88 zethTotalNew = uint88(getZethTotal(vault));  // @dev(safe-cast)\n    uint88 zethTotal = Vault.zethTotal;\n    uint88 zethCollateral = Vault.zethCollateral;\n    uint88 zethTreasury = TAPP.ethEscrowed;\n\n    if (zethTotalNew <= zethTotal) return;\n\n    uint88 yield = zethTotalNew - zethTotal;\n    Vault.zethTotal = zethTotalNew;\n\n    if (zethCollateral == 0) {\n        TAPP.ethEscrowed += yield;\n        return;\n    }\n\n    uint88 zethTreasuryReward = yield.mul(zethTreasury).divU88(zethTotal);\n    yield -= zethTreasuryReward;\n\n    uint88 tithe = yield.mulU88(Vault.zethTithePercent());\n    yield -= tithe;\n\n    TAPP.ethEscrowed += zethTreasuryReward + tithe;\n\n    Vault.zethCollateralReward += yield;\n    Vault.zethYieldRate += yield.divU80(zethCollateral);\n}\n```
MEDIUM severity: The `didTransferShares` function in the `StakeAllocator` contract lacks an access control modifier, . The `didTransferShares` function in the `StakeAllocator` contract lacks an access control modifier, allowing any user to call the function with arbitrary parameters. This function is intended to transfer shares and rewards allocation for delegated staking, and is currently accessible from the `Forta...

Vulnerable code:
```\nfunction _beforeTokenTransfer(\n    address operator,\n    address from,\n    address to,\n    uint256[] memory ids,\n    uint256[] memory amounts,\n    bytes memory data\n) internal virtual override {\n    for (uint256 i = 0; i < ids.length; i++) {\n        if (FortaStakingUtils.isActive(ids[i])) {\n            uint8 subjectType = FortaStakingUtils.subjectTypeOfShares(ids[i]);\n            if (subjectType == DELEGATOR_NODE_RUNNER_SUBJECT && to!= address(0) && from!= address(0)) {\n                _allocator.didTransferShares(ids[i], subjectType, from, to, amounts[i]);\n            }\n        }\n    }\n}\n```\n```\nfunction didTransferShares(\n    uint256 sharesId,\n    uint8 subjectType,\n    address from,\n    address to,\n    uint256 sharesAmount\n) external {\n    _rewardsDistributor.didTransferShares(sharesId, subjectType, from, to, sharesAmount);\n}\n```
MEDIUM severity: The vulnerability lies in the calculation of the maximum possible depositable amount for delta-neutr. The vulnerability lies in the calculation of the maximum possible depositable amount for delta-neutral vaults in the GMXReader contract. Specifically, the `_maxTokenBLending` calculation is incorrect, which can lead to potential issues when determining the maximum amount of tokens that can be borrow...

Vulnerable code:
```\nif (self.delta == GMXTypes.Delta.Neutral):\n    (uint256 _tokenAWeight,) = tokenWeights(self)\n\n    uint256 _maxTokenALending = convertToUsdValue(\n        self,\n        address(self.tokenA),\n        self.tokenALendingVault.totalAvailableAsset()\n    ) * SAFE_MULTIPLIER / (self.leverage * _tokenAWeight / SAFE_MULTIPLIER)\n\n    uint256 _maxTokenBLending = convertToUsdValue(\n        self,\n        address(self.tokenB),\n        self.tokenBLendingVault.totalAvailableAsset()\n    ) * SAFE_MULTIPLIER / (self.leverage * _tokenAWeight / SAFE_MULTIPLIER) - 1e18\n```\n```\nTotal value to deposit to GMX = lv\nValue of tokens to short = lva\n\nHence this value will be borrowed from the tokenA lending vault\nRemaining value to borrow (from tokenB lending vault) = lv - lva - v\nHence if there is Tb value of tokens in tokenB lending vault, v <= Tb / (l - la - 1)\n```
MEDIUM severity: The vulnerability in `DirectBuyIssuer.sol` lies in the handling of escrow records when an order is c. The vulnerability in `DirectBuyIssuer.sol` lies in the handling of escrow records when an order is cancelled or filled. When a market buy is initiated, the operator takes the payment token as escrow before filling the order. However, if the user cancels the order or the order is filled, the escrow r...

Vulnerable code:
```\nbytes32 orderId = getOrderIdFromOrderRequest(orderRequest, salt);\nuint256 escrow = getOrderEscrow[orderId];\nif (amount > escrow) {\n    revert AmountTooLarge();\n}\n\n// Update escrow tracking\ngetOrderEscrow[orderId] = escrow - amount;\n\n// Notify escrow taken\nemit EscrowTaken(orderId, orderRequest.recipient, amount);\n\n// Take escrowed payment\nIERC20(orderRequest.paymentToken).safeTransfer(msg.sender, amount);\n```\n```\nfunction _cancelOrderAccounting(\n    OrderRequest calldata order,\n    bytes32 orderId,\n    OrderState memory orderState\n) internal virtual override {\n    // Prohibit cancel if escrowed payment has been taken and not returned or filled\n    uint256 escrow = getOrderEscrow[orderId];\n    if (orderState.remainingOrder!= escrow) revert UnreturnedEscrow();\n\n    // Standard buy order accounting\n    super._cancelOrderAccounting(order, orderId, orderState);\n}\n```\n```\nfunction returnEscrow(OrderRequest calldata orderRequest, bytes32 salt, uint256 amount)\n    external\n    onlyRole(OPERATOR_ROLE)\n{\n    if (amount == 0) {\n        revert ZeroValue();\n    }\n    bytes32 orderId = getOrderIdFromOrderRequest(orderRequest, salt);\n    uint256 remainingOrder = getRemainingOrder(orderId);\n    uint256 escrow = getOrderEscrow[orderId];\n    if (escrow + amount > remainingOrder) {\n        revert AmountTooLarge();\n    }\n}\n```
MEDIUM severity: The vulnerability allows malicious users to manipulate the rebalancing logic by setting allocations . The vulnerability allows malicious users to manipulate the rebalancing logic by setting allocations to a protocol that is blacklisted. This is achieved by exploiting the `setDeltaAllocationsInt` function, which increments the `deltaAllocations` mapping and updates the `deltaAllocatedTokens` variable...

Vulnerable code:
```\nvaults[_vaultNumber].deltaAllocationProtocol[_chainId][i] = 0;\n```\n```\nfunction setDeltaAllocationsInt(uint256 _protocolNum, int256 _allocation) internal {\n    require(!controller.getProtocolBlacklist(vaultNumber, _protocolNum), "Protocol on blacklist");\n    deltaAllocations[_protocolNum] += _allocation;\n    deltaAllocatedTokens += _allocation;\n}\n```
MEDIUM severity: The `upgradeContract` function in the RocketDAONodeTrustedUpgrade codebase contains a hardcoded list. The `upgradeContract` function in the RocketDAONodeTrustedUpgrade codebase contains a hardcoded list of contracts that are exempt from being upgraded. This list is defined within the `upgradeContract` function and includes contracts that manage their own settings (statevars) or hold value within the...

Vulnerable code:
```\nfunction _upgradeContract(string memory _name, address _contractAddress, string memory _contractAbi) internal {\n    bytes32 nameHash = keccak256(abi.encodePacked(_name));\n    require(nameHash!= keccak256(abi.encodePacked("rocketVault")), \n        "Cannot upgrade the vault");\n    require(nameHash!= keccak256(abi.encodePacked("rocketPoolToken")), \n        "Cannot upgrade token contracts");\n    require(nameHash!= keccak256(abi.encodePacked("rocketTokenRETH")), \n        "Cannot upgrade token contracts");\n    require(nameHash!= keccak256(abi.encodePacked("rocketTokenNETH")), \n        "Cannot upgrade token contracts");\n    require(nameHash!= keccak256(abi.encodePacked("casperDeposit")), \n        "Cannot upgrade the casper deposit contract");\n    // Get old contract address & check contract exists\n}\n```
MEDIUM severity: The Vault_Synths.sol code fails to account for protocol exchange fees when evaluating the collateral. The Vault_Synths.sol code fails to account for protocol exchange fees when evaluating the collateral worth of a synthetic asset. This oversight can lead to inaccurate calculations, potentially resulting in underestimation or overestimation of the collateral's value.\n\nThe code does not consider the...

Vulnerable code:
```\nfunction priceCollateralToUSD(bytes32 _currencyKey, uint256 _amount) public view override returns (uint256) {\n    ILiquidityPoolAvalon LiquidityPool = ILiquidityPoolAvalon(collateralBook.liquidityPoolOf(_currencyKey));\n    uint256 tokenPrice = LiquidityPool.getTokenPrice();\n    uint256 withdrawalFee = _getWithdrawalFee(LiquidityPool);\n    uint256 USDValue = (_amount * tokenPrice) / LOAN_SCALE;\n    uint256 USDValueAfterFee = USDValue * (LOAN_SCALE - withdrawalFee) / LOAN_SCALE;\n    return USDValueAfterFee;\n}\n```
MEDIUM severity: The InfinityPool's `writeOff` function is vulnerable to an incorrect accounting of the `totalBorrowe. The InfinityPool's `writeOff` function is vulnerable to an incorrect accounting of the `totalBorrowed` value. Specifically, the function attempts to subtract the `lostAmt` from `totalBorrowed`, which is calculated as the difference between the `principalOwed` and `recoveredFunds`. However, this appr...

Vulnerable code:
```\nuint256 lostAmt = principalOwed > recoveredFunds? principalOwed - recoveredFunds : 0;\n\nuint256 totalOwed = interestPaid + principalOwed;\n\nasset.transferFrom(\n    msg.sender,\n    address(this),\n    totalOwed > recoveredFunds? recoveredFunds : totalOwed\n);\n\ntotalBorrowed -= lostAmt;\n\naccount.principal = lostAmt;\n\naccount.save(router, agentID, id);\n```
MEDIUM severity: This vulnerability involves the use of generic `address` types in Solidity contracts, which can lead. This vulnerability involves the use of generic `address` types in Solidity contracts, which can lead to reduced clarity and effectiveness of the type checker. Instead, it is recommended to use specific contract types for variables, as it provides more information about the expected contract interfac...

Vulnerable code:
```\naddress private ingressContractAddress;\n```\n```\nAccountIngress ingressContract = AccountIngress(ingressContractAddress);\n```\n```\nconstructor(address ingressAddress) public {\n```\n```\naddress private nodeIngressContractAddress;\n```
MEDIUM severity: The liquidation process for an account with a position in a market token is vulnerable to an underfl. The liquidation process for an account with a position in a market token is vulnerable to an underflow error when the total maintenance fee exceeds the account's total collateral. This occurs when the liquidation fee is calculated using the total collateral balance before the position is closed, whi...

Vulnerable code:
```\nfunction liquidate(\n    address account,\n    IProduct product\n) external nonReentrant notPaused isProduct(product) settleForAccount(account, product) {\n    if (product.isLiquidating(account)) {\n        revert CollateralAccountLiquidatingError(account);\n    }\n\n    UFixed18 totalMaintenance = product.maintenance(account);\n    UFixed18 totalCollateral = collateral(account, product);\n\n    if (!totalMaintenance.gt(totalCollateral)) {\n        revert CollateralCantLiquidate(totalMaintenance, totalCollateral);\n    }\n\n    product.closeAll(account);\n\n    // claim fee\n    UFixed18 liquidationFee = controller().liquidationFee();\n\n    UFixed18 collateralForFee = UFixed18Lib.max(totalMaintenance, controller().minCollateral());\n    UFixed18 fee = UFixed18Lib.min(totalCollateral, collateralForFee.mul(liquidationFee));\n\n    _products[product].debitAccount(account, fee);\n    token.push(msg.sender, fee);\n\n    emit Liquidation(account, product, msg.sender, fee);\n}\n```
MEDIUM severity: The vulnerability lies in the implementation of the `_decreasePairPaths` function in the RouterInfo . The vulnerability lies in the implementation of the `_decreasePairPaths` function in the RouterInfo contract. When a path is removed, the function correctly decrements the `numPathsAllowed` value of the corresponding pair in the `allowedPairsList`. However, when the last path is removed, the functio...

Vulnerable code:
```\nprivate mapping(address => mapping(address => List<Info>) allowedPairsMap;\nprivate pair[] allowedPairsList;\n```\n```\nstruct listInfo {\n    bool allowed;\n    uint256 listPosition;\n}\n\nstruct pair {\n    address token0;\n    address token1;\n    uint256 numPathsAllowed;\n}\n```\n```\nfunction _increasePairPaths(address token0, address token1) private {\n    listInfo storage LI = allowedPairsMap[token0][token1];\n\n    if (!LI.allowed) {\n        LI.allowed = true;\n        LI.listPosition = allowedPairsList.length;\n        allowedPairsList.push(pair(token0, token1, 0));\n    }\n\n    allowedPairsList[LI.listPosition].numPathsAllowed++;\n}\n```\n```\nfunction _decreasePairPaths(address token0, address token1) private {\n    listInfo storage LI = allowedPairsMap[token0][token1];\n    require(LI.allowed, "RouterInfo: pair not allowed");\n    allowedPairsList[LI.listPosition].numPathsAllowed--;\n\n    if (allowedPairsList[LI.listPosition].numPathsAllowed == 0) {\n        allowedPairsList[LI.listPosition] = allowedPairsList[allowedPairsList.length - 1];\n        allowedPairsList.pop();\n        LI.allowed = false;\n    }\n}\n```
MEDIUM severity: The `Token*` methods in the `RocketVault` contract exhibit a peculiar behavior where they either thr. The `Token*` methods in the `RocketVault` contract exhibit a peculiar behavior where they either throw or return a static value of `true`, but never return a value of `false`. This peculiarity raises questions about the necessity of the static return values, as they are not being utilized by the cal...

Vulnerable code:
```\nemit TokenDeposited(contractKey, _tokenAddress, _amount, block.timestamp);\nreturn true;\n```\n```\nemit TokenWithdrawn(contractKey, _tokenAddress, _amount, block.timestamp);\n\nreturn true;\n```\n```\nemit TokenTransfer(contractKeyFrom, contractKeyTo, _tokenAddress, _amount, block.timestamp);\nreturn true;\n```\n```\nrocketVault.depositToken("rocketNodeStaking", rplTokenAddress, _amount);\n```\n```\nrocketVault.withdrawToken(\n    msg.sender,\n    getContractAddress("rocketTokenRPL"),\n    rplAmount\n)\n```\n```\nrocketVault.withdrawToken(msg.sender, getContractAddress("rocketTokenRPL"), _amount)\n```\n```\nrocketVault.transferToken("rocketAuctionManager", \n    getContractAddress("rocketTokenRPL"), \n    rplSlashAmount)\n```
MEDIUM severity: The settlement of a batch auction can exceed the gas limit, making it impossible to settle the aucti. The settlement of a batch auction can exceed the gas limit, making it impossible to settle the auction. This occurs when the contract iterates over all bids to calculate the lot marginal price, which can be a resource-intensive operation. The contract's gas consumption can be further exacerbated by...

Vulnerable code:
```\nuint24 internal constant _MIN_BID_PERCENT = 100; // 0.1%\n```\n```\nmodifier givenBidsCreated() {\n    uint96 amountOut = 0.01e18;\n    uint96 amountIn = 0.01e18;\n    uint256 numBids = 580;\n\n    for (uint256 i = 0; i < numBids; i++) {\n        _createBid(_BIDDER, amountIn, amountOut);\n    }\n}\n\nfunction test_settleOog() external\n    givenLotIsCreated\n    givenLotHasStarted\n    givenBidsCreated\n    givenLotHasConcluded\n    givenPrivateKeyIsSubmitted\n    givenLotIsDecrypted\n{\n    uint256 gasBefore = gasleft();\n    _settle();\n\n    assert(gasBefore - gasleft() > 30_000_000);\n}\n```