Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The `FundingScript` and `RedemptionScript` functions in the code handle errors returned by the `Vend. The `FundingScript` and `RedemptionScript` functions in the code handle errors returned by the `VendingMachine` contract. When an error occurs, the `returnData` variable contains the error message, which is expected to be a string. However, the error message may be malformed due to the addition of a...

Vulnerable code:
```\nbool success, bytes memory returnData = address(vendingMachine).call(_extraData);\nrequire(success, string(returnData));\n```\n```\n(bool success, bytes memory returnData) = address(vendingMachine).call(_extraData);\n\nrequire(success, string(returnData));\n```
MEDIUM severity: The protocol's ability to receive rewards is hindered by the hardcoded gas limit of 10,000 in the `A. The protocol's ability to receive rewards is hindered by the hardcoded gas limit of 10,000 in the `Asset::transferETH()` function, which is used to transfer ETH within the protocol. This limitation is particularly problematic in the context of reward distribution, where ETH is transferred from the `...

Vulnerable code:
```\n(bool success,) = recipient.call{value: amount, gas: 10_000}('');\nif (!success) {\n    revert ETH_TRANSFER_FAILED();\n}\n```\n```\nimport { IRioLRTOperatorRegistry } from 'contracts/interfaces/IRioLRTOperatorRegistry.sol';\nimport { RioLRTOperatorDelegator } from 'contracts/restaking/RioLRTOperatorDelegator.sol';\nimport { CredentialsProofs, BeaconWithdrawal } from 'test/utils/beacon-chain/MockBeaconChain.sol';\n```\n```\nfunction test_outOfGasOnRewards() public {\n    address alice = makeAddr("alice");\n    uint256 initialBalance = 40e18;\n    deal(alice, initialBalance);\n    vm.prank(alice);\n    reETH.token.approve(address(reETH.coordinator), type(uint256).max);\n\n    uint8 operatorId = addOperatorDelegator(reETH.operatorRegistry, address(reETH.rewardDistributor));\n    RioLRTOperatorDelegator operatorDelegator = \n        RioLRTOperatorDelegator(payable(reETH.operatorRegistry.getOperatorDetails(operatorId).delegator));\n\n    vm.prank(alice);\n    reETH.coordinator.depositETH{value: initialBalance}();\n\n    vm.prank(EOA, EOA);\n    reETH.coordinator.rebalance(ETH_ADDRESS);\n\n    uint40[] memory validatorIndices = new uint40[](1);\n    IRioLRTOperatorRegistry.OperatorPublicDetails memory details = \n        reETH.operatorRegistry.getOperatorDetails(operatorId);\n    bytes32 withdrawalCredentials = operatorDelegator.withdrawalCredentials();\n    beaconChain.setNextTimestamp(block.timestamp);\n    CredentialsProofs memory proofs;\n    (validatorIndices[0], proofs) = \n        beaconChain.newValidator({\n            balanceWei: 40 ether,\n            withdrawalCreds: abi.encodePacked(withdrawalCredentials)\n        });\n\n    vm.prank(details.manager);\n    reETH.operatorRegistry.verifyWithdrawalCredentials(\n        operatorId,\n        proofs.oracleTimestamp,\n        proofs.stateRootProof,\n        proofs.validatorIndices,\n        proofs.validatorFieldsProofs,\n        proofs.validatorFields\n    );\n\n    verifyAndProcessWithdrawalsForValidatorIndexes(address(operatorDelegator), validatorIndices);\n\n    delayedWithdrawalRouter.claimDelayedWithdrawals(address(operatorDelegator), 1); // Reverts for out-of-gas\n}\n```
MEDIUM severity: The `StrategyPassiveManagerUniswap` contract grants unlimited ERC20 token allowances to the `unirout. The `StrategyPassiveManagerUniswap` contract grants unlimited ERC20 token allowances to the `unirouter` contract using the `forceApprove` function. This allows the `unirouter` contract to spend an unlimited amount of tokens on behalf of the `StrategyPassiveManagerUniswap` contract. \n\nHowever, the...

Vulnerable code:
```\nfunction _giveAllowances() private {\n    IERC20Metadata(lpToken0).forceApprove(unirouter, type(uint256).max);\n    IERC20Metadata(lpToken1).forceApprove(unirouter, type(uint256).max);\n}\n```\n```\nfunction setUnirouter(address _unirouter) external onlyOwner {\n    unirouter = _unirouter;\n    emit SetUnirouter(_unirouter);\n}\n```
MEDIUM severity: The vulnerability lies in the lack of reentrancy protection in token interactions, specifically in t. The vulnerability lies in the lack of reentrancy protection in token interactions, specifically in the `univTransfer` function. This function may potentially re-enter the system, allowing a reentrant `ERC20` token (e.g. ERC777) to call back into the `depositAndBorrow` function, leading to unintended...

Vulnerable code:
```\nfunction univTransfer(\n    IERC20 token,\n    address payable to,\n    uint256 amount\n) internal {\n    if (amount > 0) {\n        if (isFTM(token)) {\n            (bool sent, ) = to.call{ value: amount }("");\n            require(sent, "Failed to send Ether");\n        } else {\n            token.safeTransfer(to, amount);\n        }\n    }\n}\n```\n```\n/**\n * @dev Paybacks the underlying asset and withdraws collateral in a single function call from activeProvider\n * @param _paybackAmount: amount of underlying asset to be payback, pass -1 to pay full amount\n * @param _collateralAmount: amount of collateral to be withdrawn, pass -1 to withdraw maximum amount\n */\nfunction paybackAndWithdraw(int256 _paybackAmount, int256 _collateralAmount) external payable {\n    updateF1155Balances();\n    _internalPayback(_paybackAmount);\n    _internalWithdraw(_collateralAmount);\n}\n```\n```\n/**\n * @dev Paybacks Vault's type underlying to activeProvider - called by users\n * @param _repayAmount: token amount of underlying to repay, or\n * pass any 'negative number' to repay full amount\n * Emits a {Repay} event.\n */\nfunction payback(int256 _repayAmount) public payable override {\n    updateF1155Balances();\n    _internalPayback(_repayAmount);\n}\n```\n```\n/**\n * @dev Deposits collateral and borrows underlying in a single function call from activeProvider\n * @param _collateralAmount: amount to be deposited\n * @param _borrowAmount: amount to be borrowed\n */\nfunction depositAndBorrow(uint256 _collateralAmount, uint256 _borrowAmount) external payable {\n    updateF1155Balances();\n    _internalDeposit(_collateralAmount);\n    _internalBorrow(_borrowAmount);\n}\n```\n```\n/**\n * @dev Borrows Vault's type underlying amount from activeProvider\n * @param _borrowAmount: token amount of underlying to borrow\n * Emits a {Borrow} event.\n */\nfunction borrow(uint256 _borrowAmount) public override nonReentrant {\n    updateF1155Balances();\n    _internalBorrow(_borrowAmount);\n}\n```\n```\ndepositAndBorrow\nupdateBalances\ninternalDeposit ->\n    ERC777(collateralAsset).safeTransferFrom()  # calls back!\n    callback:beforeTokenTransfer\n   !! depositAndBorrow\n    updateBalances\n    internalDeposit\n    --> ERC777.safeTransferFrom()\n<_deposit\n    mint\n    internalBorrow\n    mint\n    _borrow\n    ERC777(borrowAsset).univTransfer(msg.sender)  # might call back\n\n<_deposit\n    mint\n    internalBorrow\n    mint\n    _borrow\n    --> ERC777(borrowAsset).univTransfer(msg.sender)  # might call back\n```
MEDIUM severity: The `Unable to transfer fee reserve assets to treasury` vulnerability is a critical issue in the `Tr. The `Unable to transfer fee reserve assets to treasury` vulnerability is a critical issue in the `TreasuryAction.sol` contract, which is responsible for managing the transfer of fee reserve assets to the treasury manager contract. Specifically, the `_redeemAndTransfer` function, which is called by t...

Vulnerable code:
```\nFile: TreasuryAction.sol\n\nfunction _redeemAndTransfer(uint16 currencyId, int256 primeCashRedeemAmount) private returns (uint256) {\n    PrimeRate memory primeRate = PrimeRateLib.buildPrimeRateStateful(currencyId);\n    int256 actualTransferExternal = \n        TokenHandler.withdrawPrimeCash(\n            treasuryManagerContract,\n            currencyId,\n            primeCashRedeemAmount.neg(),\n            primeRate,\n            true // if ETH, transfers it as WETH\n        );\n\n    require(actualTransferExternal > 0);\n    return uint256(actualTransferExternal);\n}\n```
MEDIUM severity: The `Goldivault.redeemYield()` function in the Goldivault smart contract is vulnerable to a reentran. The `Goldivault.redeemYield()` function in the Goldivault smart contract is vulnerable to a reentrancy attack due to the presence of a `beforeTokenTransfer` hook in the `YieldToken` contract. This hook allows the attacker to manipulate the `redeemYield()` function by repeatedly calling it within the...

Vulnerable code:
```\nfunction redeemYield(uint256 amount) external {\n    if (amount == 0) {\n        revert InvalidRedemption();\n    }\n    if (block.timestamp < concludeTime + delay ||!concluded) {\n        revert NotConcluded();\n    }\n    uint256 yieldShare = FixedPointMathLib.divWad(amount, ERC20(yt).totalSupply());\n    YieldToken(yt).burnYT(msg.sender, amount);\n    uint256 yieldTokensLength = yieldTokens.length;\n    for (uint8 i = 0; i < yieldTokensLength; ++i) {\n        uint256 finalYield;\n        if (yieldTokens[i] == depositToken) {\n            finalYield = ERC20(yieldTokens[i]).balanceOf(address(this)) - depositTokenAmount;\n        } else {\n            finalYield = ERC20(yieldTokens[i]).balanceOf(address(this));\n        }\n        uint256 claimable = FixedPointMathLib.mulWad(finalYield, yieldShare);\n        SafeTransferLib.safeTransfer(yieldTokens[i], msg.sender, claimable);\n    }\n    emit YieldTokenRedemption(msg.sender, amount);\n}\n```
MEDIUM severity: The `contribute` function in the Presale contract allows contributors to deposit Ether or a contribu. The `contribute` function in the Presale contract allows contributors to deposit Ether or a contribution token, depending on the `contributionToken` variable. The function checks if the state is set to `Funding` and verifies the contribution value. If the contribution token is set to Ether, the func...

Vulnerable code:
```\nfunction contribute(address _contributor, uint256 _value) external payable nonReentrant auth(CONTRIBUTE_ROLE) {\n    require(state() == State.Funding, ERROR_INVALID_STATE);\n\n    if (contributionToken == ETH) {\n        require(msg.value == _value, ERROR_INVALID_CONTRIBUTE_VALUE);\n    } else {\n        require(msg.value == 0, ERROR_INVALID_CONTRIBUTE_VALUE);\n    }\n\n    _contribute(_contributor, _value);\n}\n```
MEDIUM severity: The `LibChainlinkOracle` library is vulnerable to a denial-of-service (DoS) attack due to its inabil. The `LibChainlinkOracle` library is vulnerable to a denial-of-service (DoS) attack due to its inability to properly handle the composite `roundID` structure used by Chainlink. The `roundID` is a combination of `phaseID` and `aggregatorRoundID`, which changes whenever the underlying aggregator is upg...

Vulnerable code:
```\nfunction getRoundData(uint80 _roundId)\n    public\n    view\n    virtual\n    override\n    returns (\n      uint80 roundId,\n      int256 answer,\n      uint256 startedAt,\n      uint256 updatedAt,\n      uint80 answeredInRound\n    )\n{\n    (uint16 phaseId, uint64 aggregatorRoundId) = parseIds(_roundId);\n\n    (\n      uint80 roundId,\n      int256 answer,\n      uint256 startedAt,\n      uint256 updatedAt,\n      uint80 answeredInRound\n    ) = phaseAggregators[phaseId].getRoundData(aggregatorRoundId);\n\n    return addPhaseIds(roundId, answer, startedAt, updatedAt, answeredInRound, phaseId);\n}\n```\n```\nfunction latestRoundData()\n    public\n    view\n    virtual\n    override\n    returns (\n        uint80 roundId,\n        int256 answer,\n        uint256 startedAt,\n        uint256 updatedAt,\n        uint80 answeredInRound\n    ) {\n    Phase memory current = currentPhase; // cache storage reads\n\n    (\n        uint80 roundId,\n        int256 answer,\n        uint256 startedAt,\n        uint256 updatedAt,\n        uint80 answeredInRound\n    ) = current.aggregator.latestRoundData();\n\n    return addPhaseIds(\n        roundId,\n        answer,\n        startedAt,\n        updatedAt,\n        answeredInRound,\n        current.id\n    );\n}\n```
MEDIUM severity: The vulnerability lies in the implementation of Bitcoin SPV proofs in the system, which does not sup. The vulnerability lies in the implementation of Bitcoin SPV proofs in the system, which does not support transactions with a large number of inputs and outputs. This is due to the restriction on the number of inputs and outputs in a transaction, denoted by a leading "varint" - a variable length inte...

Vulnerable code:
```\nfunction validateVin(bytes memory _vin) internal pure returns (bool) {\n    uint256 _offset = 1;\n    uint8 _nIns = uint8(_vin.slice(0, 1)[0]);\n\n    if (_nIns >= 0xfd || _nIns == 0) {\n        return false;\n    }\n}\n```\n```\nfunction determineOutputLength(bytes memory _output) internal pure returns (uint256) {\n    uint8 _len = uint8(_output.slice(8, 1)[0]);\n    require(_len < 0xfd, "Multi-byte VarInts not supported");\n\n    return _len + 8 + 1; // 8 byte value, 1 byte for _len itself\n}\n```\n```\nfunction findAndParseFundingOutput(\n    DepositUtils.Deposit storage _d,\n    bytes memory _txOutputVector,\n    uint8 _fundingOutputIndex\n) public view returns (bytes8) {\n```\n```\nfunction validateAndParseFundingSPVProof(\n    DepositUtils.Deposit storage _d,\n    bytes4 _txVersion,\n    bytes memory _txInputVector,\n    bytes memory _txOutputVector,\n    bytes4 _txLocktime,\n    uint8 _fundingOutputIndex,\n    bytes memory _merkleProof,\n    uint256 _txIndexInBlock,\n    bytes memory _bitcoinHeaders\n) public view returns (bytes8 _valueBytes, bytes memory _utxoOutpoint) {\n```\n```\nfunction provideFraudBTCFundingProof(\n    DepositUtils.Deposit storage _d,\n    bytes4 _txVersion,\n    bytes memory _txInputVector,\n    bytes memory _txOutputVector,\n    bytes4 _txLocktime,\n    uint8 _fundingOutputIndex,\n    bytes memory _merkleProof,\n    uint256 _txIndexInBlock,\n    bytes memory _bitcoinHeaders\n) public returns (bool) {\n```\n```\nfunction provideBTCFundingProof(\n    DepositUtils.Deposit storage _d,\n    bytes4 _txVersion,\n    bytes memory _txInputVector,\n    bytes memory _txOutputVector,\n    bytes4 _txLocktime,\n    uint8 _fundingOutputIndex,\n    bytes memory _merkleProof,\n    uint256 _txIndexInBlock,\n    bytes memory _bitcoinHeaders\n) public returns (bool) {\n```\n```\nfunction provideSPVFraudProof(\n    DepositUtils.Deposit storage _d,\n    bytes4 _txVersion,\n    bytes memory _txInputVector,\n    bytes memory _txOutputVector,\n    bytes4 _txLocktime,\n    bytes memory _merkleProof,\n    uint256 _txIndexInBlock,\n    uint8 _targetInputIndex,\n    bytes memory _bitcoinHeaders\n) public {\n    // Code here\n}\n```
MEDIUM severity: The `ISushiBar` interface defines a set of functions that are intended to be implemented by a contra. The `ISushiBar` interface defines a set of functions that are intended to be implemented by a contract that inherits from it. Upon examination, it appears that the `transfer` function is declared, but not utilized within the interface. This suggests that the function is unnecessary and can be safely...

Vulnerable code:
```\ninterface ISushiBar {\n    function enter(uint256 _amount) external;\n\n    function leave(uint256 _share) external;\n\n    function totalSupply() external view returns (uint256);\n\n    function balanceOf(address account) external view returns (uint256);\n\n    function transfer(address recipient, uint256 amount) external returns (bool);\n}\n```
MEDIUM severity: The `Fixed Term Bond tokens` vulnerability arises from the lack of rounding enforcement in the `depl. The `Fixed Term Bond tokens` vulnerability arises from the lack of rounding enforcement in the `deploy()` function, which allows for tokens to expire at unexpected times. The intention is to mint tokens that expire once per day, creating a uniform experience and consolidating liquidity. However, the...

Vulnerable code:
```\nexpiry = ((vesting_ + uint48(block.timestamp)) / uint48(1 days)) * uint48(1 days);\n\nuint256 tokenId = getTokenId(payoutToken_, expiry);\n\nif (!tokenMetadata[tokenId].active) {\n    _deploy(tokenId, payoutToken_, expiry);\n}\n```\n```\nfunction deploy(ERC20 underlying_, uint48 expiry_)\n    external\n    override\n    nonReentrant\n    returns (uint256)\n{\n    uint256 tokenId = getTokenId(underlying_, expiry_);\n    if (!tokenMetadata[tokenId].active) {\n        _deploy(tokenId, underlying_, expiry_);\n    }\n    return tokenId;\n}\n```\n```\nuint256 tokenId = uint256(\n    keccak256(\n        abi.encodePacked(\n            underlying_,\n            expiry_ / uint48(1 days)\n        )\n    )\n);\n```\n```\ntokenMetadata[tokenId_] = TokenMetadata(\n    True,\n    underlying_,\n    uint8(underlying_.decimals()),\n    expiry_,\n    0\n)\n```
MEDIUM severity: The `moveQuoteToken()` function in the code has a critical flaw that can lead to a bucket being decl. The `moveQuoteToken()` function in the code has a critical flaw that can lead to a bucket being declared bankrupt without reflecting the updated state in the accounting. This vulnerability arises from the fact that `moveQuoteToken()` does not include a crucial check to update the bankruptcy status w...

Vulnerable code:
```\nif (removeParams.bucketCollateral == 0 && unscaledRemaining == 0 && lpsRemaining!= 0) {\n    emit BucketBankruptcy(params_.index, lpsRemaining);\n    bucket.lps = 0;\n    bucket.bankruptcyTime = block.timestamp;\n} else {\n    bucket.lps = lpsRemaining;\n}\n```
MEDIUM severity: The vulnerability arises from a rounding error in the Solidity code, specifically in the `StrategyUt. The vulnerability arises from a rounding error in the Solidity code, specifically in the `StrategyUtils._convertStrategyTokensToBPTClaim` function. This function is responsible for converting strategy tokens to BPT claims, but due to the use of integer arithmetic and a specific precision constant (`...

Vulnerable code:
```\nint256 internal constant INTERNAL_TOKEN_PRECISION = 1e8;\nuint256 internal constant BALANCER_PRECISION = 1e18;\n```\n```\nfunction _convertStrategyTokensToBPTClaim(\n    StrategyContext memory context,\n    uint256 strategyTokenAmount\n) internal pure returns (uint256 bptClaim) {\n    require(strategyTokenAmount <= context.vaultState.totalStrategyTokenGlobal);\n    if (context.vaultState.totalStrategyTokenGlobal > 0) {\n        bptClaim = (strategyTokenAmount * context.vaultState.totalBPTHeld) / context.vaultState.totalStrategyTokenGlobal;\n    }\n}\n```\n```\nFile: Boosted3TokenPoolUtils.sol\n\nfunction _redeem(\n    ThreeTokenPoolContext memory poolContext,\n    StrategyContext memory strategyContext,\n    AuraStakingContext memory stakingContext,\n    uint256 strategyTokens,\n    uint256 minPrimary\n) internal returns (uint256 finalPrimaryBalance) {\n    uint256 bptClaim = strategyContext._convertStrategyTokensToBPTClaim(strategyTokens);\n\n    if (bptClaim == 0) {\n        return 0;\n    }\n\n    finalPrimaryBalance = _unstakeAndExitPool({\n        stakingContext: stakingContext,\n        poolContext: poolContext,\n        bptClaim: bptClaim,\n        minPrimary: minPrimary\n    });\n\n    strategyContext.vaultState.totalBPTHeld -= bptClaim;\n    strategyContext.vaultState.totalStrategyTokenGlobal -= uint256(strategyTokens);\n    strategyContext.vaultState.setStrategyVaultState();\n```
MEDIUM severity: The vulnerability allows an adversary to manipulate the interest paid to legitimate lenders by infla. The vulnerability allows an adversary to manipulate the interest paid to legitimate lenders by inflating the number of provisions in a loan. This is achieved by creating a large number of provisions using their own funds, thereby reducing the interest rate paid to other lenders. The adversary can th...

Vulnerable code:
```\nfunction sendInterests(Loan storage loan, Provision storage provision) internal returns (uint256 sent) {\n    uint256 interests = loan.payment.paid - loan.lent;\n    if (interests == loan.payment.minInterestsToRepay) {\n        sent = provision.amount + (interests / loan.nbOfPositions);\n    } else {\n        sent = provision.amount + (interests * (provision.amount)) / loan.lent;\n    }\n    loan.assetLent.checkedTransfer(msg.sender, sent);\n}\n```
MEDIUM severity: The `BondSize` mechanism, responsible for updating the size of a bond, exhibits a vulnerability in i. The `BondSize` mechanism, responsible for updating the size of a bond, exhibits a vulnerability in its implementation of the `effectiveUpdateTime` variable. This variable is intended to store the timestamp when the new bond size becomes active, after a grace period.\n\nThe issue arises from the fact...

Vulnerable code:
```\nuint128 effectiveUpdateTime;\n```\n```\nuint64 constant public WAITING_PERIOD = 2 days;\n```\n```\nself.effective_update_time = uint64(now) + WAITING_PERIOD\n```
MEDIUM severity: The vulnerability allows the previous owner of a short record to burn the NFT from the new owner. Th. The vulnerability allows the previous owner of a short record to burn the NFT from the new owner. This occurs due to the `deleteShortRecord` function not resetting and deleting the `tokenId` of the deleted short record. As a result, the deleted short record still references the transferred NFT's `to...

Vulnerable code:
```\nfunction transferShortRecord(\n    address asset,\n    address from,\n    address to,\n    uint40 tokenId,\n    STypes.NFT memory nft\n) internal {\n    AppStorage storage s = appStorage();\n    STypes.ShortRecord storage short = s.shortRecords[asset][from][nft.shortRecordId];\n    if (short.status == SR.Cancelled) {\n        revert Errors.OriginalShortRecordCancelled();\n    }\n    if (short.flaggerId!= 0) {\n        revert Errors.CannotTransferFlaggedShort();\n    }\n    // ❌ deleteShortRecord(asset, from, nft.shortRecordId);\n    uint8 id = createShortRecord(\n        asset,\n        to,\n        SR.FullyFilled,\n        short.collateral,\n        short.ercDebt,\n        short.ercDebtRate,\n        short.zethYieldRate,\n        tokenId\n    );\n    if (id == Constants.SHORT_MAX_ID) {\n        revert Errors.ReceiverExceededShortRecordLimit();\n    }\n    s.nftMapping[tokenId].owner = to;\n    s.nftMapping[tokenId].shortRecordId = id;\n}\n```
MEDIUM severity: The `D3UserQuote#getUserQuote` function in the D3UserQuota smart contract contains a critical vulner. The `D3UserQuote#getUserQuote` function in the D3UserQuota smart contract contains a critical vulnerability that can lead to inaccurate quota calculations. Specifically, a small typo in the valuation loop causes the function to query the wrong token for the exchange rate, resulting in an incorrect t...

Vulnerable code:
```\nfor (uint256 i = 0; i < tokenList.length; i++) {\n    address _token = tokenList[i];\n    (address assetDToken,) = d3Vault.getAssetInfo(_token);\n    uint256 tokenBalance = IERC20(assetDToken).balanceOf(user);\n    if (tokenBalance > 0) {\n        tokenBalance = tokenBalance.mul(d3Vault.getExchangeRate(_token));\n        (uint256 tokenPrice, uint8 priceDecimal) = ID3Oracle(d3Vault._ORACLE_()).getOriginalPrice(_token);\n        usedQuota = usedQuota + tokenBalance * tokenPrice / 10 ** (priceDecimal + tokenDecimals);\n    }\n}\n```