Closed code423n4 closed 1 year ago
ith-harvey marked the issue as sponsor disputed
The call uses the positionManager contract to store depositTimes instead of relying on the pool's record of depositTime. This is to ensure that someone who uses the position manager cannot receive an LP advantage if the bucket goes bankrupt.
In the absence of detailed scenario or PoC I'll flag this report as invalid
Picodes marked the issue as unsatisfactory: Insufficient proof
Lines of code
https://github.com/code-423n4/2023-05-ajna/blob/main/ajna-core/src/PositionManager.sol#L268 (https://github.com/code-423n4/2023-05-ajna/blob/main/ajna-core/src/PositionManager.sol#L285 https://github.com/code-423n4/2023-05-ajna/blob/main/ajna-core/src/PositionManager.sol#L367 (https://github.com/code-423n4/2023-05-ajna/blob/main/ajna-core/src/PositionManager.sol#L372
Vulnerability details
Impact
Inconsistency by relying on
depositTime
at positions hashmap instead of reading the value fromlenderInfo()
Proof of Concept
The depositTime is being read from
fromPosition.depositTime
at moveLiquidity function and not fromlenderInfo()
L268 and L285The lender might do another deposit into the bucket and therefor we would have a new
depositTime
that not updated atpositions
hashmap, this could lead to incorrect check for the Bucket BankruptThe same thing is happening on reedemPositions at L367 which could block the token owner from redeeming his positions because of the check at L372
Tools Used
Manual Review
Recommended Mitigation Steps
Read the
depositTime
fromlenderInfo()
instead of positions hashmap just like memorializePositions functionAssessed type
Other