Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The `OrchidDirectory` smart contract contains a vulnerability in its mathematical operations, which . The `OrchidDirectory` smart contract contains a vulnerability in its mathematical operations, which relies on the assumption that the ERC20 token used is capped at less than `2**128`. This assumption is critical in several functions, including `step()`, `lift()`, and `have()`, where mathematical ope...

Vulnerable code:
```\nif (name(stake.left_) == key):\n    stake.before_ += amount\nelse:\n    stake.after_ += amount\n```\n```\nuint128 local = stake.amount_;\nlocal += amount;\nstake.amount_ = local;\nemit Update(staker, stakee, local);\n\nuint128 global = stakees_[stakee].amount_;\nglobal += amount;\nstakees_[stakee].amount_ = global;\n```\n```\nreturn stake.before_ + stake.after_ + stake.amount_;\n```
MEDIUM severity: The inconsistent use of the epochBegin timestamp in the `ControllerPeggedAssetV2` contract can lead . The inconsistent use of the epochBegin timestamp in the `ControllerPeggedAssetV2` contract can lead to a scenario where user funds are locked and potentially lost. This issue arises from the fact that the `triggerNullEpoch` function and the `epochHasNotStarted` modifier use different timestamp check...

Vulnerable code:
```\nif (block.timestamp < uint256(epochStart)) {\n    revert EpochNotStarted();\n```\n```\nif (block.timestamp > epochConfig[_id].epochBegin) {\n    revert EpochAlreadyStarted();\n}\n```\n```\nfunction previewEmissionsWithdraw(uint256 _id, uint256 _assets)\n    public\n    view\n    returns (uint256 entitledAmount)\n{\n    entitledAmount = _assets.mulDivDown(emissions[_id], finalTVL[_id]);\n}\n\nuint256 entitledEmissions = previewEmissionsWithdraw(_id, _assets);\nif (epochNull[_id] == false) {\n    uint256 entitledShares = previewWithdraw(_id, _assets);\n} else {\n    entitledShares = _assets;\n}\nif (entitledShares > 0) {\n    SemiFungibleVault.asset.safeTransfer(_receiver, entitledShares);\n}\nif (entitledEmissions > 0) {\n    emissionsToken.safeTransfer(_receiver, entitledEmissions);\n}\n```
MEDIUM severity: The vulnerability lies in the lack of verification of return data from external calls during deposit. The vulnerability lies in the lack of verification of return data from external calls during deposit and redemption processes in the Notional protocol. Specifically, the `GenericToken.executeLowLevelCall` function and the `TreasuryAction` contract do not properly validate the status and return data...

Vulnerable code:
```\nFile: GenericToken.sol\n\nfunction executeLowLevelCall(\n    address target,\n    uint256 msgValue,\n    bytes memory callData\n) internal {\n    (bool status, bytes memory returnData) = target.call{value: msgValue}(callData);\n    require(status, checkRevertMessage(returnData));\n}\n```\n```\nFile: TreasuryAction.sol\n\nfor (uint256 j; j < depositData.targets.length; ++j) {\n    GenericToken.executeLowLevelCall(\n        depositData.targets[j],\n        depositData.msgValue[j],\n        depositData.callData[j]\n    );\n}\n```
MEDIUM severity: The Merkle tree implementation does not enforce the inclusion of leaf nodes, allowing for the valida. The Merkle tree implementation does not enforce the inclusion of leaf nodes, allowing for the validation of nodes other than leaves. This is achieved by providing the `checkMembership` function with a reference to a hash within the tree, rather than a leaf. Specifically, the function can be tricked...

Vulnerable code:
```\n/**\n * @notice Checks that a leaf hash is contained in a root hash\n * @param leaf Leaf hash to verify\n * @param index Position of the leaf hash in the Merkle tree\n * @param rootHash Root of the Merkle tree\n * @param proof A Merkle proof demonstrating membership of the leaf hash\n * @return True, if the leaf hash is in the Merkle tree; otherwise, False\n*/\n\nfunction checkMembership(bytes32 leaf, uint256 index, bytes32 rootHash, bytes memory proof)\n    internal\n    pure\n    returns (bool)\n{\n    require(proof.length % 32 == 0, "Length of Merkle proof must be a multiple of 32");\n\n    bytes32 proofElement;\n    bytes32 computedHash = leaf;\n    uint256 j = index;\n\n    for (uint256 i = 32; i <= proof.length; i += 32) {\n        proofElement = bytes32(keccak256(proof, i));\n        if (j % 2 == 0) {\n            computedHash = keccak256(abi.encodePacked(computedHash, proofElement));\n        } else {\n            computedHash = keccak256(abi.encodePacked(proofElement, computedHash));\n        }\n        j = j / 2;\n    }\n\n    return computedHash == rootHash;\n}\n```
MEDIUM severity: The vulnerability arises from the unintended behavior of the `depositUnderlyingToken` function in th. The vulnerability arises from the unintended behavior of the `depositUnderlyingToken` function in the `AccountAction` contract, which is responsible for depositing underlying tokens, including ETH, into the wfCash contract. Specifically, when the `returnExcessWrapped` parameter is set to `false`, th...

Vulnerable code:
```\nFile: wfCashLogic.sol\n\nfunction _mintInternal(\n    //...SNIP...\n    if (maxFCash < fCashAmount) {\n        uint256 fCashAmountExternal = fCashAmount * precision / uint256(Constants.INTERNAL_TOKEN_PRECISION);\n        require(fCashAmountExternal <= depositAmountExternal);\n\n        // Residual (depositAmountExternal - fCashAmountExternal) will be transferred\n        // back to the account\n        NotionalV2.depositUnderlyingToken{value: msgValue}(address(this), currencyId, fCashAmountExternal);\n\n        //...SNIP...\n    }\n\n    // Residual tokens will be sent back to msg.sender, not the receiver. The msg.sender\n    // was used to transfer tokens in and these are any residual tokens left that were not\n    // lent out. Sending these tokens back to the receiver risks them getting locked on a\n    // contract that does not have the capability to transfer them off\n    _sendTokensToReceiver(token, msg.sender, isETH, balanceBefore)\n```\n```\nFile: AccountAction.sol\n\nfunction depositUnderlyingToken(\n    address account,\n    uint16 currencyId,\n    uint256 amountExternalPrecision\n) external payable nonReentrant returns (uint256) {\n    int256 primeCashReceived = balanceState.depositUnderlyingToken(\n        msg.sender,\n        SafeInt256.toInt(amountExternalPrecision),\n        false\n    );\n```\n```\nfunction _sendTokensToReceiver(\n    IERC20 token,\n    address receiver,\n    bool isETH,\n    uint256 balanceBefore\n) private returns (uint256 tokensTransferred) {\n    uint256 balanceAfter = isETH? WETH.balanceOf(address(this)) : token.balanceOf(address(this));\n    tokensTransferred = balanceAfter - balanceBefore;\n\n    if (isETH) {\n        IERC20(address(WETH)).transfer(receiver, tokensTransferred);\n    } else if (tokensTransferred > 0) {\n        token.safeTransfer(receiver, tokensTransferred);\n    }\n}\n```
MEDIUM severity: The `tokenState.setState` function is responsible for updating the state of a token from `PROPOSED` . The `tokenState.setState` function is responsible for updating the state of a token from `PROPOSED` to `ACCEPTED` or `DELEGATED` to `ENDING_DELEGATED`. The function utilizes a complex if-else statement to determine the necessary actions based on the new state. This complexity can lead to increased g...

Vulnerable code:
```\nfunction setState(uint delegationId, State newState) internal {\n    TimeHelpers timeHelpers = TimeHelpers(contractManager.getContract("TimeHelpers"));\n    DelegationController delegationController = DelegationController(contractManager.getContract("DelegationController"));\n\n    require(newState!= State.PROPOSED, "Can't set state to proposed");\n\n    if (newState == State.ACCEPTED) {\n        State currentState = getState(delegationId);\n        require(currentState == State.PROPOSED, "Can't set state to accepted");\n\n        _state[delegationId] = State.ACCEPTED;\n        _timelimit[delegationId] = timeHelpers.getNextMonthStart();\n    } else if (newState == State.DELEGATED) {\n        revert("Can't set state to delegated");\n    } else if (newState == State.ENDING_DELEGATED) {\n        require(getState(delegationId) == State.DELEGATED, "Can't set state to ending delegated");\n        DelegationController.Delegation memory delegation = delegationController.getDelegation(delegationId);\n\n        _state[delegationId] = State.ENDING_DELEGATED;\n        _timelimit[delegationId] = timeHelpers.calculateDelegationEndTime(delegation.created, delegation.delegationPeriod, 3);\n        _endingDelegations[delegation.holder].push(delegationId);\n    } else {\n        revert("Unknown state");\n    }\n}\n```
MEDIUM severity: The `setPeriod` function in the BalanceRedirectPresale contract allows an entity with the `OPEN_ROLE. The `setPeriod` function in the BalanceRedirectPresale contract allows an entity with the `OPEN_ROLE` permission to set an arbitrary presale starting date. The function accepts a `uint64` value for the `_period` parameter, which represents the duration of the presale. However, the validation check f...

Vulnerable code:
```\nfunction _setPeriod(uint64 _period) internal {\n    require(_period > 0, ERROR_TIME_PERIOD_ZERO);\n    require(openDate == 0 || openDate + _period > getTimestamp64(), ERROR_INVALID_TIME_PERIOD);\n    period = _period;\n}\n```
MEDIUM severity: The `setOperatorLimit` function, responsible for updating the staking limit for an operator, allows . The `setOperatorLimit` function, responsible for updating the staking limit for an operator, allows the `SYS_ADMIN` to modify the limit. While increasing the limit, the function checks that the `_snapshot` is ahead of the last validator edit, denoted by `block.number`. However, the `_snapshot` param...

Vulnerable code:
```\nif (\n    operators.value[_operatorIndex].limit < _limit &&\n    StakingContractStorageLib.getLastValidatorEdit() > _snapshot\n) {\n    revert LastEditAfterSnapshot();\n}\n```
MEDIUM severity: The `PerpDepository` contract's `vault.deposit` and `vault.withdraw` functions require the amount pa. The `PerpDepository` contract's `vault.deposit` and `vault.withdraw` functions require the amount parameter to be passed in the raw decimal representation of the token, which is different from the standard 18 decimal places used for USDC and WBTC. However, some calls to these functions fail to perfo...

Vulnerable code:
```\nfunction _depositAsset(uint256 amount) private {\n    netAssetDeposits += amount;\n\n    IERC20(assetToken).approve(address(vault), amount);\n    vault.deposit(assetToken, amount);\n}\n```\n```\nfunction _rebalanceNegativePnlWithSwap(\n    uint256 amount,\n    uint256 amountOutMinimum,\n    uint160 sqrtPriceLimitX96,\n    uint24 swapPoolFee,\n    address account\n) private returns (uint256, uint256) {\n    (uint256 baseAmount, uint256 quoteAmount) = _placePerpOrder(\n        normalizedAmount,\n        isShort,\n        amountIsInput,\n        sqrtPriceLimitX96\n    );\n    vault.withdraw(assetToken, baseAmount);\n    \n    vault.deposit(quoteToken, quoteAmount);\n\n    emit Rebalanced(baseAmount, quoteAmount, shortFall);\n    return (baseAmount, quoteAmount);\n}\n```\n```\nfunction _rebalanceNegativePnlLite(contract PerpDepository) {\n    (uint256 baseAmount, uint256 quoteAmount) = _placePerpOrder(\n        normalizedAmount,\n        isShort,\n        amountIsInput,\n        sqrtPriceLimitX96\n    );\n    vault.withdraw(assetToken, baseAmount);\n```
MEDIUM severity: The vulnerability arises from the use of the `transfer()` function in the converter smart contract, . The vulnerability arises from the use of the `transfer()` function in the converter smart contract, which forwards a fixed amount of gas (2,300) to the recipient. This approach was initially intended to prevent reentrancy vulnerabilities, assuming a constant gas cost. However, the recent inclusion o...

Vulnerable code:
```\nto.transfer(address(this).balance)\n```\n```\nif (_targetToken == ETH_RESERVE_ADDRESS)\n```\n```\nmsg.sender.transfer(reserveAmount)\n```
MEDIUM severity: The `boundedSub()` function is designed to prevent overflows and underflows by bounding the result w. The `boundedSub()` function is designed to prevent overflows and underflows by bounding the result within the range of `int256` values. However, a critical flaw in the implementation of the third case causes the function to fail to achieve its goal. Specifically, the condition `a < 0 && b <= type(in...

Vulnerable code:
```\nif a < 0 and b <= type(int256).min - a:\n    return type(int256).min\n```\n```\nreturn a - b;\n```\n```\nfunction testBoundedSub() public pure returns (int256) {\n    return boundedSub(type(int256).min + 3, 4);\n}\n```
MEDIUM severity: The vulnerability lies in the implementation of the `OFTCore#sendFrom` function, which allows an att. The vulnerability lies in the implementation of the `OFTCore#sendFrom` function, which allows an attacker to exploit the blocking behavior of the layerZero protocol by submitting an excessively large `_toAddress` input. This input is a bytes calldata of arbitrary length, which can be used to pack a...

Vulnerable code:
```\nfunction sendFrom(address _from, uint16 _dstChainId, bytes calldata _toAddress, uint _amount, address payable _refundAddress, address _zroPaymentAddress, bytes calldata _adapterParams) public payable virtual override {\n    _send(_from, _dstChainId, _toAddress, _amount, _refundAddress, _zroPaymentAddress, _adapterParams);\n}\n```
MEDIUM severity: The `executeTransaction()` and `batchExecuteTransactions()` functions in the `MixinTransactions` con. The `executeTransaction()` and `batchExecuteTransactions()` functions in the `MixinTransactions` contract lack the `nonReentrant` modifier, which allows for the possibility of reentrancy attacks. This is because the developers intentionally chose not to apply the `nonReentrant` modifier to enable th...

Vulnerable code:
```\naddress currentContextAddress = currentContextAddress;\nif (currentContextAddress!= address(0)) {\n    LibRichErrors.revert(LibExchangeRichErrors.TransactionInvalidContextError(\n        transactionHash,\n        currentContextAddress_\n    ));\n}\n```
MEDIUM severity: The ERC5095.mint function in the provided smart contract is vulnerable to incorrect slippage calcula. The ERC5095.mint function in the provided smart contract is vulnerable to incorrect slippage calculation, which can result in the loss of funds for users. The function is designed to allow users to mint a specified amount of shares, but it incorrectly calculates the slippage by applying a hardcoded...

Vulnerable code:
```\nfunction mint(address r, uint256 s) external override returns (uint256) {\n    if (block.timestamp > maturity) {\n        revert Exception(\n            21,\n            block.timestamp,\n            maturity,\n            address(0),\n            address(0)\n        );\n    }\n    uint128 assets = Cast.u128(previewMint(s));\n    Safe.transferFrom(\n        IERC20(underlying),\n        msg.sender,\n        address(this),\n        assets\n    );\n    uint128 returned = IMarketPlace(marketplace).sellUnderlying(\n        underlying,\n        maturity,\n        assets,\n        assets - (assets / 100)\n    );\n    _transfer(address(this), r, returned);\n    return returned;\n```\n```\nuint128 returned = \n    IMarketPlace(marketplace).sellUnderlying(\n        underlying,\n        maturity,\n        assets,\n        assets - (assets / 100)\n    );\n```
MEDIUM severity: The `trustedForwarder` mechanism in the PeriodicPriceStrategy contract undermines the trust assumpti. The `trustedForwarder` mechanism in the PeriodicPriceStrategy contract undermines the trust assumptions in the system, allowing it to impersonate any `msg.sender` address. This is achieved through the use of the `_msgSender()` function, which returns the payable address of the message sender. This f...

Vulnerable code:
```\nmodifier onlyPrizePool {\n    require(_msgSender() == address(prizePool), "PeriodicPrizeStrategy/only-prize-pool");\n    _\n}\n```\n```\nmodifier onlyOwnerOrListener() {\n    require(_msgSender() == owner() || _msgSender() == address(periodicPrizeStrategyListener), "PeriodicPrizeStrategy/only-owner-or-listener");\n}\n```\n```\nemit PrizePoolOpened(_msgSender(), prizePeriodStartedAt);\n```\n```\nemit PrizePoolAwardStarted(\n    _msgSender(),\n    address(prizePool),\n    requestId,\n    lockBlock\n);\n```\n```\nemit PrizePoolAwarded(_msgSender(), randomNumber);\nemit PrizePoolOpened(_msgSender(), prizePeriodStartedAt);\n```\n```\nfunction _msgSender() internal override(BaseRelayRecipient, ContextUpgradeSafe) virtual view returns (address payable) {\n    return BaseRelayRecipient._msgSender();\n}\n```
MEDIUM severity: The `Balancer` contract's rebalancing functionality is impaired due to an issue with the `Stargate` . The `Balancer` contract's rebalancing functionality is impaired due to an issue with the `Stargate` router's ability to send payloads. Specifically, when attempting to transfer an ERC20 token across chains, the `Stargate` router is unable to send a payload, resulting in the transaction being reverte...

Vulnerable code:
```\nrouter.swap({\n    value: msg.value\n}(\n    _dstChainId,\n    _srcPoolId,\n    _dstPoolId,\n    payable(this),\n    _amount,\n    _computeMinAmount(_amount, _slippage),\n    IStargateRouterBase.lzTxObj({\n        dstGasForCall: 0,\n        dstNativeAmount: 0,\n        dstNativeAddr: "0x0"\n    }),\n    _dst,\n    "0x" => this is the payload that is being sent with the transaction\n));\n```\n```\nfunction testStargateRouterReverting() public {\n    vm.createSelectFork(vm.envString("MAINNET_RPC_URL"));\n\n    address stargateRouter = 0x8731d54E9D02c286767d56ac03e8037C07e01e98;\n    address DAIWhale = 0x7A8EDc710dDEAdDDB0B539DE83F3a306A621E823;\n    address DAI = 0x6B175474E89094C44Da98b954EedeAC495271d0F;\n\n    IStargateRouter.lzTxObj memory lzTxParams = IStargateRouter.lzTxObj(0, 0, "0x00");\n\n    vm.startPrank(DAIWhale);\n    vm.deal(DAIWhale, 5 ether);\n\n    IERC20(DAI).approve(stargateRouter, 1e18);\n\n    IStargateRouter(stargateRouter).swap{value: 1 ether}(\n        111, 3, 3, payable(address(this)), 1e18, 1, lzTxParams, abi.encode(address(this)), "0x"\n    );\n}\n```\n```\nfunction retryRevert(uint16 _srcChainId, bytes calldata _srcAddress, uint256 _nonce) external payable onlyOwner {\n    router.retryRevert(value: msg.value)(_srcChainId, _srcAddress, _nonce);\n}\n```
MEDIUM severity: The `TribalChief` smart contract contains multiple instances of unsafe down-casting operations, whic. The `TribalChief` smart contract contains multiple instances of unsafe down-casting operations, which can potentially lead to loss of funds. The use of types that can be packed into a single storage slot, such as `int128` and `uint128`, may be more gas-efficient, but it can also introduce hidden ris...

Vulnerable code:
```\nuser.rewardDebt = int128(user.virtualAmount * pool.accTribePerShare) / toSigned128(ACC_TRIBE_PRECISION)\n```\n```\npool.accTribePerShare = uint128(pool.accTribePerShare + ((tribeReward * ACC_TRIBE_PRECISION) / virtualSupply));\n```\n```\nuserPoolData.rewardDebt += \n    int128(virtualAmountDelta * pool.accTribePerShare) / \n    toSigned128(ACC_TRIBE_PRECISION);\n```
MEDIUM severity: The vulnerability in the `cancelManyOrders` function of the `LibOrders` contract allows for an infin. The vulnerability in the `cancelManyOrders` function of the `LibOrders` contract allows for an infinite loop to occur when attempting to cancel more than 255 orders. This is due to the use of a `uint8` variable `i` in the `for` loop, which has a maximum value of 255. The `unchecked` block in the loo...

Vulnerable code:
```\nif (s.asset[asset].orderId < 65000):\n    revert Errors.OrderIdCountTooLow()\n```\n```\nif (numOrdersToCancel > 1000):\n    revert Errors.CannotCancelMoreThan1000Orders()\n```\n```\nfunction cancelManyOrders(\n    mapping(address => mapping(uint16 => STypes.Order)) storage orders,\n    address asset,\n    uint16 lastOrderId,\n    uint16 numOrdersToCancel\n) internal {\n    uint16 prevId;\n    uint16 currentId = lastOrderId;\n    for (uint8 i = 0; i < numOrdersToCancel;) {\n        prevId = orders[asset][currentId].prevId;\n        LibOrders.cancelOrder(orders, asset, currentId);\n        currentId = prevId;\n        unchecked {\n            i++;\n        }\n    }\n}\n```\n```\nunchecked {\n    ++i;\n}\n```\n```\n// SPDX-License-Identifier: MIT\n\npragma solidity 0.8.21;\n\ncontract PoC {\n    uint256 public iterationsCount;\n\n    function infiniteForLoop(uint256 amountOfIterations) public {\n        for (uint8 i = 0; i < amountOfIterations; ) {\n            iterationsCount += 1;\n            unchecked {\n                ++i;\n            }\n        }\n    }\n}\n```
MEDIUM severity: The `buy` and `onTokenTransfer` functions in the `Crowdinvesting` contract do not effectively limit . The `buy` and `onTokenTransfer` functions in the `Crowdinvesting` contract do not effectively limit the amount of tokens that can be spent during a transaction. This vulnerability allows the owner of the price oracle to manipulate the price and potentially exploit the system.\n\nWhen an investor att...

Vulnerable code:
```\nfunction buy(uint256 _amount, address _tokenReceiver) public whenNotPaused nonReentrant {\n    uint256 currencyAmount = Math.ceilDiv(_amount * getPrice(), 10 ** token.decimals());\n}\n```
MEDIUM severity: The `TokenSale` contract contains a vulnerability in its `claim()` function, which allows blockliste. The `TokenSale` contract contains a vulnerability in its `claim()` function, which allows blocklisted investors to still claim USDC. The issue arises from an incorrect argument being passed when checking if a user is blacklisted. Specifically, the `setClaimBlock()` function is used to block users fr...

Vulnerable code:
```\nfunction setClaimBlock(address _address) external onlyRole(OPERATOR) {\n    blockClaim[_address] = true;\n}\n```\n```\nrequire(\n    uint8(epoch) > 1 &&\n   !admin.blockClaim(address(this)),\n    "TokenSale: Not time or not allowed"\n);\n```
MEDIUM severity: The vulnerability occurs when the 'Honorarium Rate' is set to 0%, which is intended to mimic the dyn. The vulnerability occurs when the 'Honorarium Rate' is set to 0%, which is intended to mimic the dynamics of private ownership. However, this setting breaks the functionality of the protocol, causing a Denial of Service (DoS) for users attempting to place a bid. The issue arises in the `placeBid` fu...

Vulnerable code:
```\nuint256 totalCollateralAmount = bid.collateralAmount + collateralAmount;\n```\n```\ndescribe('exploit', function () {\n  it('POC', async function () {\n    const instance = await getInstance({\n      auctionLengthSeconds: 300,\n      initialPeriodStartTime: (await time.latest()) + 100,\n      licensePeriod: 1000,\n    });\n    const licenseMock = await ethers.getContractAt(\n      'NativeStewardLicenseMock',\n      instance.address,\n    );\n\n    const steward = bidder2.address;\n    await licenseMock.mintToken(steward, 0);\n\n    await time.increase(300);\n\n    const bidAmount = ethers.utils.parseEther('1.0');\n    const feeAmount = await instance.calculateFeeFromBid(bidAmount);\n    const collateralAmount = feeAmount.add(bidAmount);\n\n    await expect(\n      instance.connect(bidder1).placeBid(0, bidAmount, { value: collateralAmount }),\n    ).to.be.revertedWith('EnglishPeriodicAuction: Collateral must be greater than current bid');\n\n    const extraAmt = ethers.utils.parseEther('0.1');\n    const collateralAmount1 = feeAmount.add(bidAmount).add(extraAmt);\n\n    await expect(\n      instance.connect(bidder1).placeBid(0, bidAmount, { value: collateralAmount1 }),\n    ).to.be.revertedWith('EnglishPeriodicAuction: Incorrect bid amount');\n\n    await expect(\n      instance.connect(bidder2).placeBid(0, bidAmount, { value: 0 }),\n    ).to.not.be.reverted;\n  });\n});\n```\n```\n[\n    [await owner.getAddress(), licensePeriod, 0, 10],\n]\n```