Closed c4-bot-1 closed 5 months ago
GalloDaSballo marked the issue as insufficient quality report
Funnily enough the comment states the old arbitrum functionality but the link disproves it
Recommend closing the issue as invalid
trust1995 marked the issue as unsatisfactory: Invalid
Lines of code
https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/WiseLending.sol#L225-L227 https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/WiseLending.sol#L234-L237 https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/WiseLending.sol#L239-L242
Vulnerability details
In Arbitrum, block numbers and timestamps are reliable in long term but not reliable in short term, one invariant of the block timestamp (In Arbitrum ) is that is must always be greater or 'equal' with the previous block timestamp, taking that into consideration. If the max share price was already hit by the previous block it will not change in the next block if it will have the same timestamp( as it is calculated based on timestamp) so no new operations will be possible in that block.
Impact
If 2 or more consecutive blocks will have the same timestamp and the max share price was already hit, the deposits and borrow operations will fail.
Proof of Concept
Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates the concept.
Tools Used
Manual Review
Recommended Mitigation Steps
When calling the function _compareSharePrices, save the last block number details, and always compare the block numbers timestamp, if 2 different block numbers have the same timestamp apply a different logic when calculating currentSharePriceMax
Assessed type
Context