Closed c4-bot-10 closed 5 months ago
In this report looks like there is a missunderstanding of who is a depositor in the Vaults.
The current check is correct because it validates if the caller (the depositor) has surpassed the maxDeposit limit. The check is enforced correctly on the caller because if we look at the onlyWithelisted()
modifier, this modifier checks if the caller is whitelisted to deposit on the Vault, as such, that indicates that the depositor is the caller itself.
function deposit(
address receiver
)
...
//@audit => The caller is the depositor that is validated to be whitelisted.
onlyWhiteListed
returns (uint256 shares)
{ ... }
modifier onlyWhiteListed() {
if (!settings().isAccountEnabled(msg.sender)) revert NoPermissions();
_;
}
A whitelisted depositor could decide to distribute his shares among different accounts, but, in the end, the Vault enforces that the whiteslited depositor has not exceeded the maxDeposit, even though the shares are distributed among different accounts.
0xleastwood marked the issue as duplicate of #29
0xleastwood marked the issue as satisfactory
Lines of code
https://github.com/code-423n4/2024-05-bakerfi/blob/59b1f70cbf170871f9604e73e7fe70b70981ab43/contracts/core/Vault.sol#L214
Vulnerability details
Vulnerability details
in
Vault.deposit()
We will limit the user's maximum deposit cannot exceedsettings().getMaxDepositInETH()
.First, we need to calculate
afterDeposit = msg.value + ((balanceOf(receiver) * _tokenPerETH(maxPriceAge)) / 1e18)
. The usage ofbalanceOf(msg.sender)
inside is incorrect because we ultimately deposit is intoreceiver
:_mint(receiver, shares)
. So, it should be corrected tobalanceOf(receiver)
.Impact
An incorrect calculation
afterDeposit
can result in exceedinggetMaxDepositInETH
or prematurely triggering aMaxDepositReached
revert. users may not be able to deposit properly.Recommended Mitigation
Assessed type
Context