Closed c4-bot-5 closed 2 months ago
This issue identifies the surface of the bug but fails to identify its root cause and to provide a good recommendation.
Duplicate of https://github.com/code-423n4/2024-06-size-findings/issues/144
Fixed in https://github.com/SizeCredit/size-solidity/pull/126
hansfriese marked the issue as satisfactory
hansfriese marked the issue as duplicate of #144
hansfriese marked the issue as duplicate of #238
Lines of code
https://github.com/code-423n4/2024-06-size/blob/main/src/libraries/CapsLibrary.sol#L19-L44 https://github.com/code-423n4/2024-06-size/blob/main/src/libraries/actions/Deposit.sol#L80-L82 https://github.com/code-423n4/2024-06-size/blob/main/src/libraries/Multicall.sol#L40-L42
Vulnerability details
Impact
Users can bypass configured
borrowATokenCap
when deposit underlying borrow token token viamulticall
even when it is not utilized for repaying debt.Proof of Concept
When users deposit the underlying borrow token, it will be checked if the total supply of
borrowAToken
after the user's action does not exceed the configuredborrowATokenCap
.https://github.com/code-423n4/2024-06-size/blob/main/src/libraries/actions/Deposit.sol#L81
https://github.com/code-423n4/2024-06-size/blob/main/src/libraries/CapsLibrary.sol#L52-L58
However, this can be bypassed by calling the
deposit
operation viamulticall
. When deposit is called insidemulticall
, thevalidateBorrowATokenCap
check will be skipped andvalidateBorrowATokenIncreaseLteDebtTokenDecrease
check performed after themulticall
operation is completed. It will only ensure that theborrowATokenSupplyIncrease
(transferred borrow token from the repay operation) is not greater than thedebtATokenSupplyDecrease
(burned debt from the repay operation).https://github.com/code-423n4/2024-06-size/blob/main/src/libraries/CapsLibrary.sol#L19-L44
But it not considering scenario where users not performing repay operation (both
borrowATokenSupplyIncrease
anddebtATokenSupplyDecrease
) is 0. Means user can bypass theborrowATokenCap
without doing repay operation.PoC :
Add the test inside
Multicall.t.sol
, addimport "forge-std/console.sol";
at the top of the file :Run the test :
Log output :
It can be observed that total supply exceed configured cap even without reducing caller debt.
Tools Used
Manual review
Recommended Mitigation Steps
Add
validateBorrowATokenCap
check insidevalidateBorrowATokenIncreaseLteDebtTokenDecrease
ifdebtATokenSupplyDecrease
is 0 (no repay operation) anddeposit
is called insidemulticall
(additional flag can be added whendeposit
is called inside themulticall
).Assessed type
Context