Liquid Staking
Stakelink
DeFiHardhatOracle
50,000 USDC
View results
Previous Next
Submission Details
Severity: medium
Invalid

Lack of Fee Validation in addSplitter Allows Creation of Invalid Splitters, Risking Fund Lock and Incorrect Distributions

cheatcode

Details

The addSplitter function in the LSTRewardsSplitterController contract is responsible for creating and registering new LSTRewardsSplitter instances for accounts. It's a key administrative function for managing the reward distribution system.

The vulnerability lies in the function's failure to validate the fee structure passed to the new LSTRewardsSplitter. This can lead to the creation of splitters with invalid or malicious fee configurations.

Code Snippet

function addSplitter(
address _account,
LSTRewardsSplitter.Fee[] memory _fees
) external onlyOwner {
if (address(splitters[_account]) != address(0)) revert SplitterAlreadyExists();
​
address splitter = address(new LSTRewardsSplitter(lst, _fees, owner()));
splitters[_account] = ILSTRewardsSplitter(splitter);
accounts.push(_account);
IERC677(lst).safeApprove(splitter, type(uint256).max);
}

Impact

  1. Invalid Fee Structures: Splitters could be created with fee structures that exceed 100% or have other invalid configurations.

  2. Potential for Fund Lock: If a splitter is created with an invalid fee structure, it could lead to funds being locked or distributed incorrectly.

  3. System Integrity Compromise: The overall integrity of the reward distribution system could be compromised if invalid splitters are introduced.

Scenario

  1. The owner, either maliciously or by mistake, calls addSplitter with a fee structure where the total fees exceed 100%.

  2. A new LSTRewardsSplitter is created with this invalid fee structure.

  3. When rewards are split, the splitter attempts to distribute more than 100% of the rewards, potentially leading to reverts or unexpected behavior.

  4. Funds could become locked in the splitter, or distributed incorrectly, compromising the entire reward system for that account.

Fix

To address this issue, we should implement validation of the fee structure before creating the new splitter:

  1. Add a function to calculate the total of all fees.

  2. Validate that the total fees do not exceed 100% before creating the splitter.

  3. Optionally, add additional checks for other potential fee structure issues.

contract LSTRewardsSplitterController is Ownable {
// ... existing code ...
​
function addSplitter(
address _account,
LSTRewardsSplitter.Fee[] memory _fees
) external onlyOwner {
if (address(splitters[_account]) != address(0)) revert SplitterAlreadyExists();
if (!isValidFeeStructure(_fees)) revert InvalidFeeStructure();
​
address splitter = address(new LSTRewardsSplitter(lst, _fees, owner()));
splitters[_account] = ILSTRewardsSplitter(splitter);
accounts.push(_account);
IERC677(lst).safeApprove(splitter, type(uint256).max);
}
​
function isValidFeeStructure(LSTRewardsSplitter.Fee[] memory _fees) internal pure returns (bool) {
uint256 totalFees = 0;
for (uint256 i = 0; i < _fees.length; i++) {
totalFees += _fees[i].basisPoints;
}
return totalFees <= 10000; // 10000 basis points = 100%
}
}

This fix ensures that only valid fee structures are used when creating new splitters, maintaining the integrity of the reward distribution system and preventing potential fund locks or distribution errors.

Updates

Lead Judging Commences

inallhonesty Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.