stake.link

Summary

SDLPoolCCIPController (Primary, Secondary) lack of LINK balance check before sending CCIP message

Vulnerability Details

Sending CCIP message in SDLPoolCCIPController, to be precise, when _distributeRewards and _ccipSendUpdate in PrimaryController, and _initiateUpdate in SecondaryController, the fee for sending message are using LINK instead of Native token. But there is no check of existing balance LINK is enough to send the message.

Chainlink CCIP fee can be paid using two token, Native token and LINK token. When user initiate the message (token) transfer through this CCIP in the protocol, they have this two option. But the functions mentioned only use LINK, and the contract doesn't check if LINK token to send the CCIP message is enough to cover the fee.

There is no revert condition to catch this issue.

The only revert is if (fees > maxLINKFee) revert FeeExceedsLimit(fees); which is to make sure fee is under the max fee.

Thus, when the LINK token balance is less than fee, there will still be a revert (CCIP reject the trx due to LINK token is less than required fee).

If the user initiate the CCIP message and intend to pay fee using LINK token, then the revert would be from linkToken.safeTransferFrom(msg.sender, address(sdlPoolCCIPController), fees); due to their balance is less than fees amount. But, in those SDLPoolCCIPController functions, it is still revert, but not being catch explicitly by the current code.

Impact

In the case where LINK token is below fees, there is no explicit revert

Tools Used

Manual analysis

Recommendations

Consider to check the balance of LINK token before sending CCIP message, and revert if it's not enough