20,000 USDC
View results
Submission Details
Severity: low
Valid

`setPool` function is prone to griefing

Summary

The setPool function is used both for creating a new pool and for updating it. Since we don't have different dedicated functions to update every parameter in the struct, we are forced to update some parameters using the setPool function.

Vulnerability Details

Let's say for example we want to update the p.minLoanSize parameter in our struct. There is no dedicated function for that so we have to call setPool in order to do that. The problem comes when inside the function we are checking if the p.outstandingLoans != pools[poolId].outstandingLoans

// you can't change the outstanding loans
if (p.outstandingLoans != pools[poolId].outstandingLoans)
revert PoolConfig();

In this example, if a malicious user wants to grief and not allow the pool owner to update this function, he can front run the transaction using a bot to borrow a loan from the pool, which would change the outstanding loan at that exact moment and fail the check. In a scenario where the pool's minLoanSize is something small, the malicious user could take out a minimum loan and repay it within seconds, potentially not losing any (or small amounts) of interest rate value, in an attempt to grief the pool owner.

Impact

Griefing pool owner and not allowing him to change the parameters of his pool.

Tools Used

Manual review

Recommendations

One solution would be to implement a function that allows the pool owner to "lock" his pool from being borrowed from.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!