Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The `removeLiquidity` function in the `TransactionManager` contract lacks the `nonReentrant` modifie. The `removeLiquidity` function in the `TransactionManager` contract lacks the `nonReentrant` modifier, which allows for reentrancy attacks. This vulnerability can be exploited by an attacker who can execute third-party-supplied code in the `transfer` function of a token contract before the actual ba...

Vulnerable code:
```\n/**\n * @notice This is used by any router to decrease their available\n * liquidity for a given asset.\n * @param shares The amount of liquidity to remove for the router in shares\n * @param assetId The address (or `address(0)` if native asset) of the\n * asset you're removing liquidity for\n * @param recipient The address that will receive the liquidity being removed\n */\n\nfunction removeLiquidity(\n    uint256 shares,\n    address assetId,\n    address payable recipient\n) external override {\n    // Sanity check: recipient is sensible\n    require(recipient!= address(0), "#RL:007");\n\n    // Sanity check: nonzero shares\n    require(shares > 0, "#RL:035");\n\n    // Get stored router shares\n    uint256 routerShares = issuedShares[msg.sender][assetId];\n\n    // Get stored outstanding shares\n    uint256 outstanding = outstandingShares[assetId];\n\n    // Sanity check: owns enough shares\n    require(routerShares >= shares, "#RL:018");\n\n    // Convert shares to amount\n    uint256 amount = getAmountFromIssuedShares(\n        shares,\n        outstanding,\n        Asset.getOwnBalance(assetId)\n    );\n\n    // Update router issued shares\n    // NOTE: unchecked due to require above\n    unchecked {\n        issuedShares[msg.sender][assetId] = routerShares - shares;\n    }\n\n    // Update the total shares for asset\n    outstandingShares[assetId] = outstanding - shares;\n\n    // Transfer from contract to specified recipient\n    Asset.transferAsset(assetId, recipient, amount);\n\n    // Emit event\n    emit LiquidityRemoved(\n        msg.sender,\n        assetId,\n        shares,\n        amount,\n        recipient\n    );\n}\n```
MEDIUM severity: The `_sanityCheck` mechanism in Oracle's price verification process is vulnerable to a critical issu. The `_sanityCheck` mechanism in Oracle's price verification process is vulnerable to a critical issue. The check is designed to ensure that the new price does not deviate significantly from the current price, taking into account the `PERIOD_PRICE_INCREASE_LIMIT` and `PERIOD_PRICE_DECREASE_LIMIT` fac...

Vulnerable code:
```\nuint256 maxPrice = curPrice +\n    (curPrice *\n        self.PERIOD_PRICE_INCREASE_LIMIT *\n        _periodsSinceUpdate) / PERCENTAGE_DENOMINATOR;\n\nuint256 minPrice = curPrice -\n    (curPrice *\n        self.PERIOD_PRICE_DECREASE_LIMIT *\n        _periodsSinceUpdate) / PERCENTAGE_DENOMINATOR;\n\nrequire(\n    _newPrice >= minPrice && _newPrice <= maxPrice,\n    "OracleUtils: price is insane"\n);\n```
MEDIUM severity: The WIchiFarm contract is vulnerable to a reentrancy attack due to an incorrect assumption made abou. The WIchiFarm contract is vulnerable to a reentrancy attack due to an incorrect assumption made about the IchiVaultLP's behavior. Specifically, the contract assumes that the `transferFrom` function does not reduce the allowance when the allowance is set to `type(uint256).max`. However, a deployed Ic...

Vulnerable code:
```\nfunction transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) {\n    _transfer(sender, recipient, amount);\n    _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "ERC20: transfer amount exceeds allowance"));\n    return true;\n}\n```\n```\nif (\n    IERC20Upgradeable(lpToken).allowance(\n        address(this),\n        address(ichiFarm)\n    )!= type(uint256).max\n) {\n    IERC20Upgradeable(lpToken).safeApprove(\n        address(ichiFarm),\n        type(uint256).max\n    );\n}\n```\n```\nfunction safeApprove(\n    IERC20Upgradeable token,\n    address spender,\n    uint256 value\n) internal {\n    require(\n        (value == 0) || (token.allowance(address(this), spender) == 0),\n        "SafeERC20: approve from non-zero to non-zero allowance"\n    );\n    _callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, value));\n}\n```
MEDIUM severity: The `ShareToken` contract, an extension of the Openzeppelin ERC20Mintable pattern, contains a vulner. The `ShareToken` contract, an extension of the Openzeppelin ERC20Mintable pattern, contains a vulnerability in its `mint()` method. This method allows accounts with the minter role to mint new tokens, but the return value of the method is not checked. \n\nThe ERC20 standard does not specify whether...

Vulnerable code:
```\nfunction mint(address account, uint256 amount) public onlyMinter returns (bool) {\n    _mint(account, amount);\n    return true;\n}\n```\n```\nfunction mintShareTokenTo(address guy, uint256 amount) internal {\n    shareToken.mint(guy, amount);\n}\n```
MEDIUM severity: The `SellUSSDBuyCollateral` function in the `USSDRebalancer.sol` contract contains a critical logica. The `SellUSSDBuyCollateral` function in the `USSDRebalancer.sol` contract contains a critical logical error in its collateral validation process. Specifically, the function uses a logical OR operator (`||`) to check whether the collateral token is not equal to either `uniPool.token0()` or `uniPool.t...

Vulnerable code:
```\n196 for (uint256 i = 0; i < collateral.length; i++) {\n    uint256 collateralval = IERC20Upgradeable(collateral[i].token).balanceOf(USSD) * 1e18 / (10**IERC20MetadataUpgradeable(collateral[i].token).decimals()) * collateral[i].oracle.getPriceUSD() / 1e18;\n    if (collateralval * 1e18 / ownval < collateral[i].ratios[flutter]) {\n        if (collateral[i].token!= uniPool.token0() || collateral[i].token!= uniPool.token1()) {\n            IUSSD(USSD).UniV3SwapInput(collateral[i].pathbuy, daibought / portions);\n        }\n    }\n}\n```
MEDIUM severity: The `RewardsDistributor` contract is vulnerable to an issue when handling deposits of fee-on-transfe. The `RewardsDistributor` contract is vulnerable to an issue when handling deposits of fee-on-transfer incentive tokens. Specifically, when receiving fee-on-transfer tokens and storing the reward amount, the contract does not account for the fee deducted from the transfer amount in-transit. This can...

Vulnerable code:
```\nfunction _depositLPIncentive(\n    StoredReward memory reward,\n    uint256 amount,\n    uint256 periodReceived\n) private {\n    IERC20(reward.token).safeTransferFrom(\n        msg.sender,\n        address(this),\n        amount\n    );\n\n    _storeReward(periodReceived, reward, amount);\n}\n```
MEDIUM severity: The `Ownable` contract contains a function named `renounceOwnership()` which, when called, allows th. The `Ownable` contract contains a function named `renounceOwnership()` which, when called, allows the owner to relinquish their ownership of the contract. This function is inherited by several contracts in the protocol, including `SDLPoolCCIPControllerPrimary`, `SDLPoolCCIPControllerSecondary`, `Wra...

Vulnerable code:
```\nit('renounce ownership', async () => {\n    console.log("Owner before", await controller.owner())\n    await controller.setMaxLINKFee(toEther(100))\n    console.log("Set max link fee with onlyOwner modifier", await controller.maxLINKFee())\n\n    await expect(controller.renounceOwnership())\n    await expect(controller.setMaxLINKFee(toEther(200))).to.be.revertedWith('Ownable: caller is not the owner')\n    console.log("set max link fee hasn't changed", await controller.maxLINKFee())\n    console.log("Owner after", await controller.owner())\n})\n```
MEDIUM severity: The vulnerability lies in the way pending rewards are handled in the BlueBerryBank and WCurveGauge c. The vulnerability lies in the way pending rewards are handled in the BlueBerryBank and WCurveGauge contracts. Specifically, the `pendingRewards` function in WCurveGauge returns empty arrays when called, which means that the pending rewards are not accurately reflected in the position's collateral va...

Vulnerable code:
```\naddress[] memory tokens, uint256[] memory rewards = IERC20Wrapper(\n    pos.collToken\n).pendingRewards(pos.collId, pos.collateralSize);\n\nfor (uint256 i; i < tokens.length; i++) {\n    rewardsValue += oracle.getTokenValue(tokens[i], rewards[i]);\n}\n```\n```\nfunction pendingRewards(\n    uint256 tokenId,\n    uint256 amount\n)\n    public\n    view\n    override\nreturns (address[] memory tokens, uint256[] memory rewards)\n```
MEDIUM severity: The freeze mechanism in this contract introduces a significant reduction in the borrowableAmount, th. The freeze mechanism in this contract introduces a significant reduction in the borrowableAmount, thereby decreasing the yield for lenders. This occurs due to the difference in the unlocking times of the two freeze intervals, `mintFreezeInterval` and `freezeBuckets.interval`. \n\nWhen a user deposit...

Vulnerable code:
```\nfunction _mintInternal(address _receiver, uint _balanceIncreased, uint _totalAsset)\n    internal\n    returns (uint mintShares)\n{\n    unfreezeTime[_receiver] = block.timestamp + mintFreezeInterval;\n\n    if (freezeBuckets.interval > 0) {\n        FreezeBuckets.addToFreezeBuckets(freezeBuckets, _balanceIncreased.toUint96());\n    }\n}\n```
MEDIUM severity: The `updateContract()` method in the `ERC1538UpdateDelegate` contract contains a critical implementa. The `updateContract()` method in the `ERC1538UpdateDelegate` contract contains a critical implementation flaw. Specifically, it fails to correctly parse function signatures when encountering specific streams of bytes. This issue arises from the method's attempt to parse a `string` input, which is re...

Vulnerable code:
```\nif (char == 0x3B)  # 0x3B = ';'\n    return 0\n```
MEDIUM severity: The vulnerability lies in the calculation of the maximum external lending amount, which can exceed t. The vulnerability lies in the calculation of the maximum external lending amount, which can exceed the external withdrawal threshold. This threshold is designed to ensure that Notional has sufficient liquidity to withdraw from an external lending market, thereby maintaining the redeemability of its...

Vulnerable code:
```\n700 / 1300 = 0.5384615385 (53%)\n```\n```\nFile: ExternalLending.sol\n\nfunction getTargetExternalLendingAmount(\n    uint256 maxExternalUnderlyingLend;\n\n    uint256 maxExternalUnderlyingLend;\n    if (oracleData.currentExternalUnderlyingLend < oracleData.externalUnderlyingAvailableForWithdraw) {\n        maxExternalUnderlyingLend = (\n            oracleData.externalUnderlyingAvailableForWithdraw\n            - oracleData.currentExternalUnderlyingLend\n        ).mul(uint256(Constants.PERCENTAGE_DECIMALS))\n       .div(rebalancingTargetData.externalWithdrawThreshold);\n    } else {\n        maxExternalUnderlyingLend = 0;\n    }\n```
MEDIUM severity: The vulnerability lies in the lack of explicit checks for entity initialization in the creation proc. The vulnerability lies in the lack of explicit checks for entity initialization in the creation process. Specifically, the `initiator` modifier, which is responsible for initializing entities such as Planet, Comet, and Operator, does not verify that the entity has been properly initialized before al...

Vulnerable code:
```\nmodifier initiator(\n    DataStoreUtils.DataStore storage DATASTORE,\n    uint256 _TYPE,\n    uint256 _id,\n    address _maintainer\n) {\n    require(\n        msg.sender == DataStoreUtils.DataStore.readAddressForId(_id, "CONTROLLER"),\n        "MaintainerUtils: sender NOT CONTROLLER"\n    );\n    require(\n        DataStoreUtils.DataStore.readUintForId(_id, "TYPE") == _TYPE,\n        "MaintainerUtils: id NOT correct TYPE"\n    );\n    require(\n        DataStoreUtils.DataStore.readUintForId(_id, "initiated") == 0,\n        "MaintainerUtils: already initiated"\n    );\n\n    DataStoreUtils.DataStore.writeAddressForId(_id, "maintainer", _maintainer);\n\n    DataStoreUtils.DataStore.writeUintForId(_id, "initiated", block.timestamp);\n\n    emit IdInitiated(_id, _TYPE);\n}\n```
MEDIUM severity: The vulnerability lies in the handling of the `getAmplificationParameter()` function's precision in . The vulnerability lies in the handling of the `getAmplificationParameter()` function's precision in the `MetaStable2TokenAuraHelper.sol` and `Boosted3TokenAuraHelper.sol` contracts. This function returns a tuple containing the amplification parameter value, a boolean indicating whether the value is...

Vulnerable code:
```\nfunction reinvestReward(\n    MetaStable2TokenAuraStrategyContext calldata context,\n    ReinvestRewardParams calldata params\n)\n```\n```\noracleContext._validateSpotPriceAndPairPrice({\n    poolContext: poolContext,\n    strategyContext: strategyContext,\n    primaryAmount: primaryAmount,\n    secondaryAmount: secondaryAmount\n})\n```\n```\nuint256 spotPrice = _getSpotPrice(oracleContext, poolContext, 0);\n```\n```\nuint256 balanceX, uint256 balanceY = \n    tokenIndex == 0 \n   ? (poolContext.primaryBalance, poolContext.secondaryBalance) \n    : (poolContext.secondaryBalance, poolContext.primaryBalance);\n\nuint256 invariant = \n    StableMath._calculateInvariant(\n        oracleContext.ampParam, \n        StableMath._balances(balanceX, balanceY), \n        true // round up\n    );\n\nspotPrice = \n    StableMath._calcSpotPrice({\n        amplificationParameter: oracleContext.ampParam,\n        invariant: invariant,\n        balanceX: balanceX,\n        balanceY: balanceY\n    });\n```\n```\n(\n    uint256 value,\n    bool isUpdating,\n    uint256 precision\n) = IMetaStablePool(address(BALANCER_POOL_TOKEN)).getAmplificationParameter();\n```\n```\n/**************************************************************************************************************\n// 2.a.x.y + a.y^2 + b.y\nspot price Y/X = - dx/dy = -----------------------\n// 2.a.x.y + a.x^2 + b.x\n\nn = 2\na = amp param * n\nb = D + a.(S - D)\nD = invariant\nS = sum of balances but x,y = 0 since x  and y are the only tokens\n**************************************************************************************************************/\n```\n```\nuint256 internal constant _AMP_PRECISION = 1e3;\n```\n```\nuint256 a = (amplificationParameter * 2) / _AMP_PRECISION;\n```\n```\nfunction reinvestReward(\n    Boosted3TokenAuraStrategyContext calldata context,\n    ReinvestRewardParams calldata params\n)\n```\n```\nuint256 minBPT = context.poolContext._getMinBPT(\n    oracleContext, \n    strategyContext, \n    primaryAmount\n);\n```\n```\nminBPT = StableMath._calcBptOutGivenExactTokensIn({\n    amp: oracleContext.ampParam,\n    balances: balances,\n    amountsIn: amountsIn,\n    bptTotalSupply: virtualSupply,\n    swapFeePercentage: 0,\n    currentInvariant: invariant\n})\n```\n```\nuint256 newInvariant = _calculateInvariant(amp, newBalances, false);\nuint256 invariantRatio = newInvariant / currentInvariant;\n```\n```\nuint256 ampTimesTotal = amplificationParameter * numTokens;\n```\n```\n(\n  uint256 value,\n  bool isUpdating,\n  uint256 precision\n) = pool.getAmplificationParameter();\n```
MEDIUM severity: The `LootBox` contract, deployed with `LootBoxController`, serves as a proxy for individual `create2. The `LootBox` contract, deployed with `LootBoxController`, serves as a proxy for individual `create2` lootbox contracts. Unfortunately, none of the methods in the `LootBox` implementation contract are access restricted, allowing a malicious actor to exploit the `executeCalls()` function. This functi...

Vulnerable code:
```\nfunction executeCalls(Call[] calldata calls) external returns (bytes[] memory) {\n    bytes[] memory response = new bytes[](calls.length);\n    for (uint256 i = 0; i < calls.length; i++) {\n        response[i] = _executeCall(calls[i].to, calls[i].value, calls[i].data);\n    }\n    return response;\n}\n```
MEDIUM severity: The `_update()` function, which is internally called by `mint()`, `burn()`, and `swap()` functions, . The `_update()` function, which is internally called by `mint()`, `burn()`, and `swap()` functions, contains a potential vulnerability due to an arithmetic overflow. The code block in question calculates the `timeElapsed` variable as the difference between the current block timestamp (`blockTimestam...

Vulnerable code:
```\nuint256 timeElapsed = blockTimestamp - blockTimestampLast;\n\nif (timeElapsed > 0 && _reserve0!= 0 && _reserve1!= 0) {\n    reserve0CumulativeLast += _reserve0 * timeElapsed;\n    reserve1CumulativeLast += _reserve1 * timeElapsed;\n}\n```
MEDIUM severity: The `RewardsDistributor::triggerRoot` function is vulnerable to abuse, allowing an attacker to manip. The `RewardsDistributor::triggerRoot` function is vulnerable to abuse, allowing an attacker to manipulate the `root` state and block reward claims. This function can be called by anyone, which is a critical issue, as it allows unauthorized parties to modify the `root` state without proper authorizat...

Vulnerable code:
```\nfunction triggerRoot() external {\n    bytes32 rootCandidateAValue = rootCandidateA.value;\n    if (rootCandidateAValue!= rootCandidateB.value || rootCandidateAValue == bytes32(0)) {\n        revert RootCandidatesInvalid();\n    }\n    root = Root({value: rootCandidateAValue, lastUpdatedAt: block.timestamp});\n    emit RootChanged(msg.sender, rootCandidateAValue);\n}\n```
MEDIUM severity: The vulnerability lies in the inefficient gas consumption of the bounty and slashing distribution me. The vulnerability lies in the inefficient gas consumption of the bounty and slashing distribution mechanisms within the smart contract. Specifically, the code iterates over all active delegators using a `for` loop, which results in a significant gas cost. This limitation restricts the number of acti...

Vulnerable code:
```\nfor (uint i = 0; i < shares.length; ++i) {\n    skaleToken.send(address(skaleBalances), shares[i].amount, abi.encode(shares[i].holder));\n\n    uint created = delegationController.getDelegation(shares[i].delegationId).created;\n    uint delegationStarted = timeHelpers.getNextMonthStartFromDate(created);\n    skaleBalances.lockBounty(shares[i].holder, timeHelpers.addMonths(delegationStarted, 3));\n}\n```\n```\nfunction slash(uint validatorId, uint amount) external allow("SkaleDKG") {\n    ValidatorService validatorService = ValidatorService(contractManager.getContract("ValidatorService"));\n    require(validatorService.validatorExists(validatorId), "Validator does not exist");\n\n    Distributor distributor = Distributor(contractManager.getContract("Distributor"));\n    TokenState tokenState = TokenState(contractManager.getContract("TokenState"));\n\n    Distributor.Share[] memory shares = distributor.distributePenalties(validatorId, amount);\n\n    for (uint i = 0; i < shares.length; i++) {\n        tokenState.slash(shares[i].delegationId, shares[i].amount);\n    }\n}\n```
MEDIUM severity: The `BuyUSSDSellCollateral` function in the `USSD.sol` contract is responsible for rebalancing the U. The `BuyUSSDSellCollateral` function in the `USSD.sol` contract is responsible for rebalancing the USSD pool during a peg-down recovery. When collateral is sold for DAI, the function should ensure that DAI is not sold for DAI, as there is no path to sell DAI for DAI. However, the function does not p...

Vulnerable code:
```\nif (collateralval > amountToBuyLeftUSD) {\n    if (collateral[i].pathsell.length > 0) {\n        uint256 amountBefore = IERC20Upgradeable(baseAsset).balanceOf(USSD);\n        uint256 amountToSellUnits = IERC20Upgradeable(collateral[i].token).balanceOf(USSD) * ((amountToBuyLeftUSD * 1e18 / collateralval) / 1e18) / 1e18;\n        IUSSD(USSD).UniV3SwapInput(collateral[i].pathsell, amountToSellUnits);\n        amountToBuyLeftUSD -= (IERC20Upgradeable(baseAsset).balanceOf(USSD) - amountBefore);\n        DAItosell += (IERC20Upgradeable(baseAsset).balanceOf(USSD) - amountBefore);\n    } else {\n        DAItosell = IERC20Upgradeable(collateral[i].token).balanceOf(USSD) * amountToBuyLeftUSD / collateralval;\n    }\n}\n\nelse {\n    if (collateralval >= amountToBuyLeftUSD / 20) {\n        uint256 amountBefore = IERC20Upgradeable(baseAsset).balanceOf(USSD);\n        IUSSD(USSD).UniV3SwapInput(collateral[i].pathsell, IERC20Upgradeable(collateral[i].token).balanceOf(USSD));\n        amountToBuyLeftUSD -= (IERC20Upgradeable(baseAsset).balanceOf(USSD) - amountBefore);\n        DAItosell += (IERC20Upgradeable(baseAsset).balanceOf(USSD) - amountBefore);\n    }\n}\n```
MEDIUM severity: The `liquidateSecondary` function in the protocol's smart contract is responsible for emitting event. The `liquidateSecondary` function in the protocol's smart contract is responsible for emitting events detailing the liquidation process of secondary positions. Specifically, it emits an event named `LiquidateSecondary` that includes information about the positions that were liquidated, as well as th...

Vulnerable code:
```\nfunction liquidateSecondary(\n    address asset,\n    MTypes.BatchMC[] memory batches,\n    uint88 liquidateAmount,\n    bool isWallet\n) external \n    onlyValidAsset(asset)\n    isNotFrozen(asset)\n    nonReentrant \n{\n    // Initial code\n\n    emit Events.LiquidateSecondary(asset, batches, msg.sender, isWallet);\n}\n```
MEDIUM severity: The vulnerability allows a malicious trader to intentionally obtain `dittoMatchedShares` by exploiti. The vulnerability allows a malicious trader to intentionally obtain `dittoMatchedShares` by exploiting a specific edge case in the system's order book management. The malicious trader can create a bid order using the `BidOrdersFacet::createBid()` function at an extremely low price, which is unlikely...

Vulnerable code:
```\nMarket status:\n    assetX: current price 100\n```
MEDIUM severity: The vulnerability lies in the lack of segregation between users' assets and collected fees in the `L. The vulnerability lies in the lack of segregation between users' assets and collected fees in the `LimitOrderRegistry` contract. This allows the owner to withdraw all the Native ETH and ERC20 WETH tokens, including those belonging to users, without any restrictions. This can result in an irreversibl...

Vulnerable code:
```\nFile: LimitOrderRegistry.sol\n\nfunction claimOrder(uint128 batchId, address user) external payable returns (ERC20, uint256) {\n    // Transfer tokens owed to user.\n    tokenOut.safeTransfer(user, owed);\n\n    // Transfer fee in.\n    address sender = _msgSender();\n    if (msg.value >= userClaim.feePerUser) {\n        // Refund if necessary.\n        uint256 refund = msg.value - userClaim.feePerUser;\n        if (refund > 0) {\n            sender.safeTransferETH(refund);\n        }\n    } else {\n        WRAPPED_NATIVE.safeTransferFrom(sender, address(this), userClaim.feePerUser);\n        // If value is non zero send it back to caller.\n        if (msg.value > 0) {\n            sender.safeTransferETH(msg.value);\n        }\n    }\n```\n```\nFile: LimitOrderRegistry.sol\n\nfunction withdrawNative() external onlyOwner {\n    uint256 wrappedNativeBalance = WRAPPED_NATIVE.balanceOf(address(this));\n    uint256 nativeBalance = address(this).balance;\n\n    // Make sure there is something to withdraw.\n    if (wrappedNativeBalance == 0 && nativeBalance == 0) {\n        revert LimitOrderRegistry__ZeroNativeBalance();\n    }\n\n    // transfer wrappedNativeBalance if it exists\n    if (wrappedNativeBalance > 0) {\n        WRAPPED_NATIVE.safeTransfer(owner, wrappedNativeBalance);\n    }\n    // transfer nativeBalance if it exists\n    if (nativeBalance > 0) {\n        owner.safeTransferETH(nativeBalance);\n    }\n}\n```