Issues would arise as lastBalance or totalSupply hit 2**112

Summary

There's no cap on total supply or total assets and this would cause a lot of issues when they hit 2**112 which is the max storage allocated for them.

Vulnerability Detail

totalSupply and lastBalance are safe cast to uint112 before storing.

totalSupply is the number of shares in circulation and this value can increase outside of deposit or mints. It is increased by minting shares to reserve when profit is accrued
lastBalance is the asset balance that's tracked
inventory is a memory variable that's used to track lastBalance + totalBorrowed with interest

It is possible to reach a total supply or lastBalance that's close to or equal to uint112.max during a deposit. And then at a later time, exceed the max because of interest accrual. This could put the contract in a stalemate because of reverts in _save. This scenario is more likely with tokens of high decimals such as 27 because 1e27 is less than 5.2 millions away from uint112.max.

Impact

Lender could be in stalemate when totalSupply exceeds 2**112 because of interest accrual.

Code Snippet

https://github.com/sherlock-audit/2023-10-aloe/blob/main/aloe-ii/core/src/Ledger.sol#L359-L365 https://github.com/sherlock-audit/2023-10-aloe/blob/main/aloe-ii/core/src/Lender.sol#L556-L557

Tool used

Manual Review

Recommendation

uint112 is a small amount and there are multiple recommendations

Use the maxMint and check that every mint won't exceed that.
Use maxDeposit but instead of just setting it to 2**96, use _convertToAsset(maxMint()). The extra step is to be fully ERC4626 compliant
Warn users against using the contract with high decimals or tokens that print trillions. The contract is unsuitable for large amounts.

sherlock-audit / 2023-10-aloe-judging

0x007 - Issues would arise as lastBalance or totalSupply hit 2**112 #116