DVP's _mint/_burn function could be DoS by FeeManager.
Summary
Attacker could deploy malicious contract which conform to IDVP interface, then use it to call FeeManager.trackVaultFee(), set vaultFeeAmounts[vault] to max uint, make DVP's _mint/_burn (and IG's mint/burn) function unusable.
Thus, there is an exploit path:
1, Attacker deploy a malicious contract that conform to IDVP and has 'vault' variable equals to victim IG's vault.
2, Attacker use this contract to call FeeManager.trackVaultFee(), set vaultFeeAmounts[vault] to max uint
3, Now in the situation when common user try to call mint/burn function in IG, and vault fee is not zero, function will revert due to vaultFeeAmounts[vault] overflow in FeeManager.trackVaultFee().
4, Because this is no other way to change or decrease vaultFeeAmounts[vault], this IG will lose it's mint/burn function forever.
Malicous contract example below:
// SPDX-License-Identifier: BUSL-1.1
pragma solidity ^0.8.15;
interface IFeeManager {
function trackVaultFee(address vault, uint256 feeAmount) external;
function vaultFeeAmounts(address) external view returns(uint256);
}
contract Attack {
address public vault;
address public feeManager;
constructor(address IGVaultAddr, address feeManagerAddr) {
vault = IGVaultAddr; // send victim IG's vault here.
feeManager = feeManagerAddr;
}
function attack() public {
IFeeManager FM = IFeeManager(feeManager);
// caculate how much vault fee to add to reach max uint.
uint256 toMaxUint = type(uint256).max - FM.vaultFeeAmounts(vault);
// set vaultFeeAmounts[vault] to max uint.
FM.trackVaultFee(vault, toMaxUint);
}
...
}
bearonbike
medium
DVP's _mint/_burn function could be DoS by FeeManager.
Summary
Attacker could deploy malicious contract which conform to IDVP interface, then use it to call FeeManager.trackVaultFee(), set vaultFeeAmounts[vault] to max uint, make DVP's _mint/_burn (and IG's mint/burn) function unusable.
Vulnerability Detail
In DVP, _burn and _mint function use FeeManager.trackVaultFee() to record vault fee: https://github.com/sherlock-audit/2024-02-smilee-finance/blob/main/smilee-v2-contracts/src/DVP.sol#L178 https://github.com/sherlock-audit/2024-02-smilee-finance/blob/main/smilee-v2-contracts/src/DVP.sol#L329
In FeeManager.trackVaultFee(), vault fee is recorded in public mapping vaultFeeAmounts: https://github.com/sherlock-audit/2024-02-smilee-finance/blob/main/smilee-v2-contracts/src/FeeManager.sol#L218-L227
Thus, there is an exploit path: 1, Attacker deploy a malicious contract that conform to IDVP and has 'vault' variable equals to victim IG's vault. 2, Attacker use this contract to call FeeManager.trackVaultFee(), set vaultFeeAmounts[vault] to max uint 3, Now in the situation when common user try to call mint/burn function in IG, and vault fee is not zero, function will revert due to vaultFeeAmounts[vault] overflow in FeeManager.trackVaultFee(). 4, Because this is no other way to change or decrease vaultFeeAmounts[vault], this IG will lose it's mint/burn function forever.
Malicous contract example below:
Impact
The mint/burn function of DVP/IG could be Dos.
Code Snippet
https://github.com/sherlock-audit/2024-02-smilee-finance/blob/main/smilee-v2-contracts/src/DVP.sol#L120-L195 https://github.com/sherlock-audit/2024-02-smilee-finance/blob/main/smilee-v2-contracts/src/DVP.sol#L231-L332 https://github.com/sherlock-audit/2024-02-smilee-finance/blob/main/smilee-v2-contracts/src/FeeManager.sol#L218-L227
Tool used
Manual Review
Recommendation
The key of exploit is anyone could call trackVaultFee, add access control so that only dvp can call trackVaultFee is a solution.
Duplicate of #43