Steadefi

Summary

• If adding liquidity to GMX get canceled after a failed withdrawal, the contract stuck in the withdraw_failed status.

Vulnerability Details

• The status withdraw_failed is set when the vault successfully withdrew from GMX, but the callback failed during the processWithdraw() checks inside the try call, as seen here:

the keeper listens to events in this scenario, it calls the processWithdrawFailure() function. This function reborrows the same amount's :

it then add liquidity to gmx :

The problem arises when adding liquidity to GMX is canceled, there is no mechanism to handle this scenario when the status is withdraw_failed. In this case, the callback will revert, as seen here, leaving the tokens from the first withdrawal + borrowed tokens stuck in the contract with the withdraw_failed status.

In this situation, the only available action to interact with the contract is to call processWithdrawFailure() again (or emergencyPause).

Even if the keeper can call this without any event listening, doing so exacerbates the situation. It results in a loop of borrow more => add liquidity => get canceled, continuing until there are no more funds to borrow or the keeper runs out of gas.

• Another issue arises when there is insufficient funds in the lending contract for borrowing, as this function does not check the capacity before borrowing. This results in repeated reverting transactions since the amount the keeper want to borrow is more then the amount available in the lending contract.

Impact

• Renders users unable to withdraw or deposit funds, halting essential interactions with the protocol.

• Poses a risk of failing to rebalance the contract, potentially resulting in bad debt accumulation.

Tools Used

vs code.

Recommendations

• In the afterWithdrawalCancellation() function of the callback contract, implement proper handling for canceled liquidity addition when the status is withdraw_Failed.