Since there is a 15 min cooldown duration after minting GLP,
The 'GlpManager' contract of GMX has a 'cooldownDuration' limit on redeem/unstake ('_removeLiquidity()'). While there is at least one deposit/stake ('_addLiquidity()') operation in the past 'cooldownDuration' time, redemption would fail. Obviously this limitation is user-based, and 'PirexGmx' contract is one such user.
We canCall function should not only check if the signature match but also should check if the last deposit timestamp to make sure no malicious user keep calling the stake with small amount to block redeem function.
ctf_sec
high
Redeem on GMX can be blocked because of cooldown duration limit on redeem and unstake on GMX side
Summary
Redeem on GMX can be blocked because of cooldown duration limit on redeem and unstake on GMX side
Vulnerability Detail
In the current integration, the code integrate with the GMX reward router integrate with 4 methods:
However, according to the documentation of the GMX:
https://gmxio.gitbook.io/gmx/contracts#transferring-staked-glp
The 'GlpManager' contract of GMX has a 'cooldownDuration' limit on redeem/unstake ('_removeLiquidity()'). While there is at least one deposit/stake ('_addLiquidity()') operation in the past 'cooldownDuration' time, redemption would fail. Obviously this limitation is user-based, and 'PirexGmx' contract is one such user.
https://github.com/gmx-io/gmx-contracts/blob/c3618b0d6fc1b88819393dc7e6c785e32e78c72b/contracts/core/GlpManager.sol#L234
Due to this limit, a user can keep deposit and mint for 1 WEI and block deposit.
Impact
UnStakeAndRedeem function can be blocked because of the GMX cooldown period.
Code Snippet
https://github.com/sherlock-audit/2023-01-sentiment/blob/main/controller-55/src/gmx/RewardRouterV2Controller.sol#L52
Tool used
Manual Review
Recommendation
We canCall function should not only check if the signature match but also should check if the last deposit timestamp to make sure no malicious user keep calling the stake with small amount to block redeem function.