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-15 MitigationConfirmed #110

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

M-15 MitigationConfirmed #110

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

Comments

@c4-bot-1
Copy link
Contributor

Lines of code

Vulnerability details

C4 Issue

M-15: confirmUnderwriter() need to recalculate getMinTimeBetweenWithdrawalQueues

Comments

Original vulnerabilities/impacts:
The issue raises an edge case where changing the underwriter contract might result in existing immutable getMinTimeBetweenWithdrawalQueues too be too small. When getMinTimeBetweenWithdrawalQueues is too small, when a loan is paid off, the loanId’s associated queue might have already been deleted.

Mitigation

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

//src/lib/loans/LoanManager.sol
    function setUnderwriter(address __underwriter) external onlyOwner {
...
        if (IPoolOfferHandler(__underwriter).getMaxDuration() > IPoolOfferHandler(getUnderwriter).getMaxDuration()) {
            revert InvalidInputError();
        }
...

The mitigation is to check the new underwriter max loan duration (IPoolOfferHandler(__underwriter).getMaxDuration()), and ensure that the new max loan duration is not greater than the existing max loan duration.

The mitigation resolves the issue because as long as the max loan duration will not be reduced, the total maximum duration a loan may take from initiation to liquidation settlement will not be reduced, which means that the existing getMinTimeBetweenWithdrawalQueues will still be valid.

Conclusion

LGTM

@c4-judge
Copy link

c4-judge commented Jun 1, 2024

alex-ppg marked the issue as satisfactory

@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 confirmed for report

@c4-judge c4-judge added the confirmed for report This issue is confirmed for report label Jun 1, 2024
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-15 satisfactory satisfies C4 submission criteria; eligible for awards
Projects
None yet
Development

No branches or pull requests

2 participants