You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Yield Generation will start accrual before periodStart.
Summary
The updateYield function has a faulty check that causes Yield to begin accruing immediately, even if periodStart is set to a future date. As a result, if startYieldDistribution is called with a future periodStart, it has no effect, and Yield begin accumulating right away. This is problematic because the code intends for periodStart to allow setting a start time in the future, as long as it’s not in the past.
Following action will result in this vulnerability.
CONTRACT_DISTRIBUTION_MODULE needs to call startYieldDistribution and the periodStart in future
Whenever any user call deposit function the reward accumulation will start despite the fact that the reward periodStart is still in future.
the only check $.isActive is true.
External pre-conditions
The user only need to deposit into vault before the yield periodStart time.
Attack Path
The CONTRACT_DISTRIBUTION_MODULE role calls the startYieldDistribution and set the periodStart after 1 day.
The user calls deposit function and the yield will start accumulation for it.
Impact
The only impact it has is that the yield accumulation will not respect the periodStart time and start accumulation as the CONTRACT_DISTRIBUTION_MODULE role set the reward distribution.
PoC
No response
Mitigation
Following suggestion will fix this issue :
diff --git a/pegasus/packages/solidity/src/vaults/YieldBearingVault.sol b/pegasus/packages/solidity/src/vaults/YieldBearingVault.sol
index 626d1de..da8e4fd 100644
--- a/pegasus/packages/solidity/src/vaults/YieldBearingVault.sol+++ b/pegasus/packages/solidity/src/vaults/YieldBearingVault.sol@@ -122,7 +122,7 @@ abstract contract YieldBearingVault is ERC4626Upgradeable {
*/
function _calculateEarnedYield() internal view virtual returns (uint256) {
YieldDataStorage storage $ = _getYieldDataStorage();
- if (!$.isActive) return 0;+ if (!$.isActive || block.timestamp < $.periodStart) return 0;
if (block.timestamp <= $.lastUpdateTime) {
return 0;
}
@@ -137,7 +137,7 @@ abstract contract YieldBearingVault is ERC4626Upgradeable {
*/
function _updateYield() internal virtual {
YieldDataStorage storage $ = _getYieldDataStorage();
- if (!$.isActive) return;+ if (!$.isActive || block.timestamp < $.periodStart) return;
The text was updated successfully, but these errors were encountered:
sherlock-admin4
changed the title
Active Sandstone Lemur - The Yield Generation will start accrual before periodStart.
aman - The Yield Generation will start accrual before periodStart.
Nov 19, 2024
aman
High
The Yield Generation will start accrual before
periodStart
.Summary
The
updateYield
function has a faulty check that causes Yield to begin accruing immediately, even ifperiodStart
is set to a future date. As a result, ifstartYieldDistribution
is called with a futureperiodStart
, it has no effect, and Yield begin accumulating right away. This is problematic because the code intends forperiodStart
to allow setting a start time in the future, as long as it’s not in the past.Root Cause
https://github.com/sherlock-audit/2024-10-usual-labs-v1/blob/main/pegasus/packages/solidity/src/vaults/YieldBearingVault.sol#L140
Internal pre-conditions
Following action will result in this vulnerability.
CONTRACT_DISTRIBUTION_MODULE
needs to callstartYieldDistribution
and theperiodStart
in futuredeposit
function the reward accumulation will start despite the fact that the rewardperiodStart
is still in future.$.isActive
is true.External pre-conditions
The user only need to deposit into vault before the yield
periodStart
time.Attack Path
CONTRACT_DISTRIBUTION_MODULE
role calls thestartYieldDistribution
and set theperiodStart
after 1 day.deposit
function and the yield will start accumulation for it.Impact
The only impact it has is that the yield accumulation will not respect the
periodStart
time and start accumulation as theCONTRACT_DISTRIBUTION_MODULE
role set the reward distribution.PoC
No response
Mitigation
Following suggestion will fix this issue :
The text was updated successfully, but these errors were encountered: