[High] _mint 函数中的错误加法操作

在 _mint 函数中，对于非质押账户的条件块中存在错误的加法操作。nonStakingSupply += nonStakingSupply; 应更改为 nonStakingSupply += _amount;，因为它意图将非质押供应量增加以发行的数量，而不是以其自身的先前值。

    // contracts/tokens/BaseToken.sol
    function _mint(address _account, uint256 _amount) internal {
        require(_account != address(0), "BaseToken: mint to the zero address");

        _updateRewards(_account);

        totalSupply += _amount;
        balances[_account] += _amount;

        if (nonStakingAccounts[_account]) {
            nonStakingSupply += nonStakingSupply;//@audit 
        }

        emit Transfer(address(0), _account, _amount);
    }

Recommended

将加法操作更正为 nonStakingSupply += _amount;。

[High] withdraw function index error

The exploitable logical vulnerability in the provided Smart Contract code lies within the handling mechanisms in the withdraw function, specifically how the refinanced status of each token ID is checked and modified. The issue arises from the premature removal of tokenRefinanceInfos entries before checking all token IDs in the withdraw request. This approach allows a user to potentially manipulate and bypass the refinanced status check for subsequent token IDs in a batch withdrawal, leading to unauthorized actions like double withdrawal.

poc:

1. Initial Setup:
   • Assume a user _user has previously deposited two or more NFTs from the same contract _nft into the smart contract, and these NFTs have distinct token IDs, say tokenId1 and tokenId2.
   • These tokens were not marked as refinanced initially (hasRefinanced = false).
2. Preparation for Withdrawal:
   • Generate a withdrawal request for both tokenId1 and tokenId2 from the same NFT collection _nft in the same transaction using the withdraw function.
   • Order the token IDs in the batch withdrawal such that tokenId1 is listed before tokenId2.
3. Manipulating Token Status:
   • When processing tokenId1, the contract checks hasRefinanced status, finds it false, and proceeds with withdrawal.
   • The contract removes the tokenRefinanceInfo of tokenId1 by replacing it with the last in the list and then popping the last element – reducing the array by one.
   • This alteration modifies the indexing of tokenRefinanceInfos. If tokenId2 was right next to tokenId1 in the list initially, its index is now decremented by one.
4. Exploiting Faulty Logic:
   • The contract now proceeds to check tokenId2.
   • Due to alteration from the previous step, if the array had only two items (tokenId1 and tokenId2), tokenId2 now occupies the index previously held by tokenId1.
   • The compromised logic does not accommodate the altered indexing, which implies the check for tokenId2 could either reference an incorrect item or skip checks as it might wrongly assume the length constraint fails.
5. Outcome of Exploitation:
   • This flaw could allow tokenId2 (and potentially others) to bypass the crucial hasRefinanced check, thereby allowing withdrawals even if they might have been refinanced or should not be eligible for withdrawal.
   • This kind of exploitation directly leads to unauthorized withdrawal or double-spending of NFTs, essentially causing a breach of user assets stored or managed in the smart contract.

Recommendations:

• To prevent such indexing issues after array modifications, ensure thorough re-validation of token statuses or defer all deletions in tokenRefinanceInfos until after all validations and withdrawals are processed for an entire batch.
• Alternatively, consider maintaining a more robust and error-resistant state management for token tracking that doesn't rely strictly on array ordering or real-time modification during processing loops.