Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

M-16 MitigationConfirmed #111

Open
c4-bot-8 opened this issue May 24, 2024 · 2 comments
Open

M-16 MitigationConfirmed #111

c4-bot-8 opened this issue May 24, 2024 · 2 comments
Labels
confirmed for report This issue is confirmed for report mitigation-confirmed MR-M-16 satisfactory satisfies C4 submission criteria; eligible for awards

Comments

@c4-bot-8
Copy link
Contributor

Lines of code

Vulnerability details

C4 Issue

M-16: distribute() Use the wrong end time to break maxSeniorRepayment's expectations

Comments

Original vulnerabilities/impacts:
The issue raises the case where maxSeniorRepayment set by tranches can be violated during the loan liquidation auction settlement flow, because the payment for senior tranches is calculated with inflated interests. Interests are calculated with block.timstamp instead of loan.endTime.

Due to the bidding process, actual block.timestamp when a liquidation is settled will pass loan.endTime, this violates the check on maxSeniorRepayment of each tranche during loan initiation which uses loan.endTime.

Mitigation

Fix: https://github.com/pixeldaogg/florida-contracts/pull/389/files

//src/lib/LiquidationDistributor.sol
    function distribute(uint256 _proceeds, IMultiSourceLoan.Loan calldata _loan) external {
...
        uint256 loanEndTime = _loan.startTime + _loan.duration;
...
        for (uint256 i = 0; i < _loan.tranche.length;) {
            IMultiSourceLoan.Tranche calldata thisTranche = _loan.tranche[i];
            uint256 pendingInterest =
|>              thisTranche.principalAmount.getInterest(thisTranche.aprBps, loanEndTime - thisTranche.startTime);
            totalPrincipalAndPaidInterestOwed += thisTranche.accruedInterest;
            totalPendingInterestOwed += pendingInterest;
            owedPerTranche[i] += thisTranche.principalAmount + thisTranche.accruedInterest + pendingInterest;
            unchecked {
                ++i;
            }
        }
...

The mitigation is to use loan.endTime to calculate pending interests in distribute() flow:
(1) In distribute() flow, uint256 pendingInterest calculation is revised to use loan.endTime. This also corrects owedPerTranche[i] and totalPendingInterestOwed;
(2) In _handleTrancheExcess(), the tranche owed amount is also calculated using _loanEndTime.

The above corrects the calculation of pending interest and tranche owed amounts, which resolves the issue.

Test

The revised test is passing.

Conclusion

LGTM

c4-bot-1 added a commit that referenced this issue May 24, 2024
@c4-judge c4-judge added the satisfactory satisfies C4 submission criteria; eligible for awards label Jun 1, 2024
@c4-judge
Copy link

c4-judge commented Jun 1, 2024

alex-ppg marked the issue as satisfactory

@c4-judge c4-judge added the confirmed for report This issue is confirmed for report label Jun 1, 2024
@c4-judge
Copy link

c4-judge commented Jun 1, 2024

alex-ppg marked the issue as confirmed for report

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
confirmed for report This issue is confirmed for report mitigation-confirmed MR-M-16 satisfactory satisfies C4 submission criteria; eligible for awards
Projects
None yet
Development

No branches or pull requests

2 participants