Potential Reentrancy Issues in the `mint` Function

[hats-bug-reporter[bot]]

Github username: @Jelev123 Twitter username: zhulien_zhelev Submission hash (on-chain): 0x059de4224c25adfd07eebf4530b9b3f2c8d2c8f9be63d9b6d1ad6c296ee5f4f3 Severity: medium

Description: Description\ Posible reentrancy in function mint

CVX.transferFrom(msg.sender, address(this), amount); is setted before

cvxToLock += amount; this brake Checks-Effects-Interactions Pattern.

Attack Scenario\ If an attacker could reenter the mint function during its execution (particularly after the cvxToLock += amount line has executed), they could repeatedly execute the line cvxToLock += amount without the corresponding amount of CVX actually being transferred or locked. Nested mint Calls: Each reentrant call to mint increases cvxToLock by amount again, without necessarily having the actual CVX tokens to back up these increments.

1. Proof of Concept (PoC) File

https://github.com/hats-finance/Convergence---Convex-integration-0xb3df23e155b74ad2b93777f58980d6727e8b40bb/blob/b3c66b1323cd555f5fa784b12736fd9b8f9ddfc5/contracts/Staking/Convex/cvgCVX/CvxConvergenceLocker.sol#L220-L223

Recommendation

Reentrancy Guard: Implement a reentrancy guard to prevent any function from being reentrant. This could be a simple state variable that tracks if the contract is currently executing.

Checks-Effects-Interactions Pattern: Modify the function to follow this pattern more strictly. Update the state (cvxToLock += amount;) before performing any external calls.

[PlamenTSV]

CVX is not an ERC777 and callbacks occur only when users receive such tokens