DeFiHardhat
35,000 USDC
View results
Submission Details
Severity: low
Invalid

Possible Reentrancy attack on `_claimPlenty` function

Summary

The _claimPlenty function transfers the earned "plenty" (tokens) to the specified account. The plenty is earned during a Season of Plenty (SOP) and stored in the sop.plenty field of the account's storage.

Vulnerability Details

The potential reentrancy issue arises because the function transfers tokens to the account before deleting the sop.plenty field. This creates a window of opportunity for reentrancy attacks.

An attacker could create a malicious contract that implements a fallback function or another function that calls _claimPlenty. If the attacker's contract is passed as the account argument to _claimPlenty, it could re-enter the _claimPlenty function multiple times within the same transaction before the sop.plenty field is deleted, ultimately draining the contract's token balance.

See the following code:

/**
* @dev Gas optimization: An account can call `{SiloFacet:claimPlenty}` even
* if `s.a[account].sop.plenty == 0`. This would emit a ClaimPlenty event
* with an amount of 0.
*/
function _claimPlenty(address account) internal {
// Plenty is earned in the form of the non-Bean token in the SOP Well.
uint256 plenty = s.a[account].sop.plenty;
IWell well = IWell(s.sopWell);
IERC20[] memory tokens = well.tokens();
IERC20 sopToken = tokens[0] != C.bean() ? tokens[0] : tokens[1];
sopToken.safeTransfer(account, plenty);
delete s.a[account].sop.plenty;
emit ClaimPlenty(account, address(sopToken), plenty);
}

Impact

If an attacker successfully exploits the reentrancy vulnerability, they could repeatedly call the _claimPlenty function within the same transaction, each time receiving the token transfer and resetting the sop.plenty field. This could result in an undesired depletion of tokens from the contract's balance, leading to financial loss or disruption of contract logic.

Tools Used

Manual Review

Recommendations

To mitigate the reentrancy issue, the contract should follow the "Checks-Effects-Interactions" pattern, where state changes are performed before interacting with external contracts. Specifically, the deletion of the sop.plenty field should be done before the transfer.

Updates

Lead Judging Commences

giovannidisiena Lead Judge over 1 year ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement
Assigned finding tags:

Informational/Invalid

Support

FAQs

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