Incorrect safeApprove usage

[code423n4]

Lines of code

https://github.com/code-423n4/2023-08-dopex/blob/eb4d4a201b3a75dd4bddc74a34e9c42c71d0d12f/contracts/reLP/ReLPContract.sol#L150

Vulnerability details

Impact

The safeApprove function of the OpenZeppelin SafeERC20 library prevents changing an allowance between non-zero values to mitigate a possible front-running attack. Instead, the safeIncreaseAllowance and safeDecreaseAllowance

Proof of Concept

https://github.com/code-423n4/2023-08-dopex/blob/eb4d4a201b3a75dd4bddc74a34e9c42c71d0d12f/contracts/reLP/ReLPContract.sol#L149C1-L164C4

IERC20WithBurn(addresses.pair).safeApprove(
  addresses.ammRouter,
  type(uint256).max
);


IERC20WithBurn(addresses.tokenA).safeApprove(
  addresses.ammRouter,
  type(uint256).max
);


IERC20WithBurn(addresses.tokenB).safeApprove(
  addresses.ammRouter,
  type(uint256).max
);

}

Tools Used

manual

Recommended Mitigation Steps

use safeIncreaseAllowance and safeDecreaseAllowance instead SafeApprove

Assessed type

Token-Transfer

[c4-pre-sort]

bytes032 marked the issue as duplicate of #928

[c4-pre-sort]

bytes032 marked the issue as not a duplicate

[c4-pre-sort]

bytes032 marked the issue as duplicate of #1662

[c4-pre-sort]

bytes032 marked the issue as low quality report

[c4-judge]

GalloDaSballo marked the issue as unsatisfactory:
Out of scope