PirexGmx contract migration can be blocked

[code423n4]

Lines of code

https://github.com/code-423n4/2022-11-redactedcartel/blob/03b71a8d395c02324cb9fdaf92401357da5b19d1/src/PirexGmx.sol#L930

Vulnerability details

Impact

For migration to work correctly the contract PirexGmx is using functions from IRewardRouterV2 contract.

It has to follow a sequence of first calling setPauseState(true) then initiateMigration and the final step is for the new contract to call completeMigration.

This process can be broken by sending at least one token of (Vested GMX) vGMX or (Vested GLP) vGLP to the PirexGMX contract because:

When calling initiateMigration the old contract is signaling its intent via gmxRewardRouterV2.signalTransfer(newContract); and by doing this the called contract is checking if we have any mentioned token in the contract balance. If we do then the call is reverted and the migration is stopped.

https://github.com/code-423n4/2022-11-redactedcartel/blob/03b71a8d395c02324cb9fdaf92401357da5b19d1/src/PirexGmx.sol#L930

The migration is stopped because in the next sequence call the router (gmxRewardRouterV2) is reverting because we have failed to set the pendingReceivers (field is inside gmxRewardRouterV2 code) to our new contract address using our initiateMigration call.

// inside RewardRouterV2::acceptTransfer
require(pendingReceivers[_sender] == receiver, "RewardRouter: transfer not signalled");

The PirexGMX contract does not have any capacity to move this offending tokens out before initiating the migration process.

Proof of Concept

On both Arbitrum and Avalanche the suggested contract addresses for RewardRouterV2::signalTransfer this check is made like this:

function signalTransfer(address _receiver) external nonReentrant {
        require(IERC20(gmxVester).balanceOf(msg.sender) == 0, "RewardRouter: sender has vested tokens");
        require(IERC20(glpVester).balanceOf(msg.sender) == 0, "RewardRouter: sender has vested tokens");

        _validateReceiver(_receiver);
        pendingReceivers[msg.sender] = _receiver;
    }

Tools Used

Manual review

Recommended Mitigation Steps

And function to the PirexGMX contract owner to clear/move out the offending tokens before initiating the migration sequnence.

[c4-judge]

Picodes marked the issue as primary issue

[c4-judge]

Picodes marked the issue as satisfactory

[C4-Staff]

JeeberC4 marked the issue as duplicate of #61