The _handleReturn function calculates token amounts for transfers using division operations that could result in precision loss and potential fund locking due to insufficient balance checks and rounding errors.
Integer division rounding coupled with insufficient balance validation creates edge cases where funds can become permanently locked.
The vulnerability stems from several compounding issues:
Division before multiplication in share calculations:
OR
No validation that totalShares is non-zero before division
No check that the calculated amount is less than or equal to the contract's actual token balance
The division operation can round down to zero even when shares > 0, leading to locked funds
Users with small share amounts could have their funds permanently locked if the division rounds to zero
Contract could attempt to transfer more tokens than it has available
Mathematical precision loss could accumulate over time, leading to accounting errors
PoC:
Manual review
Slither static analyzer
Foundry testing framework
Implement SafeMath operations and minimum amount checks:
Consider implementing a minimum share amount to prevent dust amounts
Add comprehensive balance checks before transfers
Consider using fixed-point arithmetic libraries for better precision
Add emergency withdrawal function for edge cases
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
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.