The identified code segments fail to validate the return value of the transferFrom
function, which violates the ERC20 token standard security practices. Missing return value checks could allow failed token transfers to go undetected, leading to inconsistencies in contract state and potential loss of user funds.
AaveDIVAWrapperCore.sol
Lines 229-230:
AaveDIVAWrapperCore.sol
Lines 285-289:
Issue:
The ERC20 transferFrom
function returns a boolean value indicating success (true
) or failure (false
). These code segments do not check the return value, assuming transfers always succeed. However, tokens like USDT (on mainnet) or non-compliant implementations may return false
instead of reverting on failure. This could result in:
Users retaining tokens while the contract logic proceeds as if the transfer succeeded.
Incorrect accounting (e.g., recording deposits/withdrawals without actual token movements).
Users may lose tokens if the contract logic proceeds under the false assumption that transfers occurred.
Contract state inconsistencies (e.g., minting/redeeming shares without token custody).
Exploitable scenarios where malicious actors intentionally force transfer failures.
foundry
Explicit Return Value Checks:
Wrap transferFrom
calls in require
statements to enforce successful transfers:
Use SafeERC20 Library:
Replace raw transferFrom
calls with OpenZeppelin’s safeTransferFrom
from the SafeERC20
library. This handles both boolean
returns and non-compliant tokens:
Test with Non-Compliant Tokens:
Validate behavior with tokens that return false
on failure (e.g., USDT on Ethereum mainnet).
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.