Skip to content

Latest commit

 

History

History
81 lines (56 loc) · 2.69 KB

File metadata and controls

81 lines (56 loc) · 2.69 KB

Dandy Caramel Tortoise

High

Repayer can brick lending functionality of LenderCommitmentGroup_Smart by repaying excess

Summary

LenderCommitmentGroup_Smart doesn't handle excess repayments making it possible to brick the lending functionality

Root Cause

The getTotalPrincipalTokensOutstandingInActiveLoans function performs totalPrincipalTokensLended - totalPrincipalTokensRepaid without handling the underflow scenario. This is problematic as excess amount can be repaid for loans which will cause an underflow here

    function getTotalPrincipalTokensOutstandingInActiveLoans()
        public
        view
        returns (uint256)
    {
        return totalPrincipalTokensLended - totalPrincipalTokensRepaid;
    }

on excess repayments, totalPrincipalTokensRepaid will become greater than totalPrincipalTokensLended

    function repayLoanCallback(
        uint256 _bidId,
        address repayer,
        uint256 principalAmount,
        uint256 interestAmount
    ) external onlyTellerV2 whenForwarderNotPaused whenNotPaused bidIsActiveForGroup(_bidId) { 
        totalPrincipalTokensRepaid += principalAmount;
        totalInterestCollected += interestAmount;

function in TellerV2.sol contract to repay excess amount. User can specify any amount greater than minimum amount

    function repayLoan(uint256 _bidId, uint256 _amount)
        external
        acceptedLoan(_bidId, "rl")
    {
        _repayLoanAtleastMinimum(_bidId, _amount, true);
    }

The function getTotalPrincipalTokensOutstandingInActiveLoans is invoked before every lending. Hence an underflow here will cause the lending functionality to revert

Another quirk regarding excess repayments is that the lenders of the pool won't obtain the excess repaid amount since it is not accounted anywhere. But this cannot be considered an issue since the lenders are only guarenteed the original lending amount + interest

Internal pre-conditions

No response

External pre-conditions

No response

Attack Path

  1. Attacker borrows 100 from the lender pool totalPrincipalTokensLended == 100 totalPrincipalTokensRepaid == 0

  2. Attacker repays 101 totalPrincipalTokensLended == 100 totalPrincipalTokensRepaid == 101

Now getTotalPrincipalTokensOutstandingInActiveLoans will always revert

Impact

Bricked lending functionality

PoC

No response

Mitigation

In case repaid principal is more, return 0 instead