Submitted by bin2chen, also found by ladboy233
LP can set renewalCutoffTime=block.timestamp by executing reclaimLiquidity(), to force close position
The restrictions are:
Since addPremium() will modify lien.startTime = block.timestamp, we need to restrict , if lps.getRenewalCutoffTime(lien.tokenId) > lien.startTime, addPremium() cannot be executed.
Otherwise, addPremium() can indefinitely postpone liquidatePosition() to forcibly close position.
The problem is that this judgment condition is >, so if lps.getRenewalCutoffTime(lien.tokenId) == lien.startTime, it can be executed.
This leads to, the borrower can monitor the mempool, if LP executes reclaimLiquidity(), front-run or follow closely to execute addPremium(0). It can be executed successfully, resulting in lien.startTime == lps[tokenId].renewalCutoffTime == block.timestamp.
In this case, liquidatePosition() will fail  ,  because the current condition for liquidatePosition() is lien.startTime < lps.getRenewalCutoffTime(lien.tokenId), liquidatePosition() will revert Errors.LiquidationNotMet();.
So by executing reclaimLiquidity() and addPremium() in the same block, it can maliciously continuously prevent LP from retrieving Liquidity.
Malicious borrowers can follow reclaimLiquidity() then execute addPremium() to invalidate renewalCutoffTime, thereby maliciously preventing the position from being forcibly closed, and LP cannot retrieve Liquidity.
Use >= lien.startTime to replace > lien.startTime.
In this way, the borrower has at most one chance and cannot postpone indefinitely.
wukong-particle (Particle) confirmed and commented:
0xLeastwood (Judge) increased severity to High and commented:
adriro (Warden) commented:
0xleastwood (Judge) decreased severity to Medium and commented:
