Reentrancy attacks in mint function

[code423n4]

Lines of code

https://github.com/code-423n4/2022-12-tigris/blob/588c84b7bb354d20cbca6034544c4faa46e6a80e/contracts/Position.sol#L126-L161
https://github.com/code-423n4/2022-12-tigris/blob/588c84b7bb354d20cbca6034544c4faa46e6a80e/contracts/Trading.sol#L156-L210
https://github.com/code-423n4/2022-12-tigris/blob/588c84b7bb354d20cbca6034544c4faa46e6a80e/contracts/Trading.sol#L307-L349

Vulnerability details

Author: rotcivegaf

Impact

The root of the problem are in the mint who use _safeMint. This mint call the function onERC721Received of the token recipient, generating a possible reentrancy attack

Proof of Concept

A wallet can call the initiateMarketOrder or initiateLimitOrder and this functions call the mint function who inside call the OZ _safeMint
When the the _safeMint call onERC721Received of the _mintTrade.account, this one have the possibility to call functions and the lines L149-L160 of mint are not execute yet, also L207-L210 of initiateMarketOrder and L347-L348 of initiateLimitOrder
The _mintTrade.account can call:

• executeLimitOrder and avoid require(block.timestamp >= limitDelay[_id]);
• cancelLimitOrder, liquidatePosition, initiateCloseOrder and limitClose burning the nft

Tools Used

Review

Recommended Mitigation Steps

Can use reentrancy guards in the three function mint, initiateMarketOrder and initiateLimitOrder
Or use _mint instead of _safeMint

[c4-judge]

GalloDaSballo marked the issue as duplicate of #400

[c4-judge]

GalloDaSballo marked the issue as satisfactory