Closed c4-submissions closed 11 months ago
bytes032 marked the issue as insufficient quality report
No proof of impact
GalloDaSballo (sponsor) disputed
We have shared broken invariants and this one also doesn't demonstrate a valid impact, this is not weaponized
Just mark it as a dup of #199 , although they are a little different. Pls check the comment I left in the #199 and prove it should be a MED.
jhsagd76 marked the issue as duplicate of #199
jhsagd76 changed the severity to QA (Quality Assurance)
jhsagd76 marked the issue as grade-c
This previously downgraded issue has been upgraded by jhsagd76
jhsagd76 marked the issue as selected for report
jhsagd76 marked the issue as satisfactory
jhsagd76 marked the issue as not selected for report
jhsagd76 marked issue #199 as primary and marked this issue as a duplicate of 199
make sense, still maintain a 100% reward for this issue.
Lines of code
https://github.com/code-423n4/2023-10-badger/blob/f2f2e2cf9965a1020661d179af46cb49e993cb7e/packages/contracts/contracts/CdpManager.sol#L320-L328
Vulnerability details
Impact
I came across the following in the main invariants:
R-07: TCR should not decrease after redemptions.
Proof of Concept
The first
CDP
with the lowestICR
higher than theMCR
can be redeemed.Let's imagine the following scenario: There are 3
CDP
s with the same debts and different collateral shares.Then
This implies that the
second CDP
can beredeemable
. After redeeming thesecond CDP
, theTCR
obviously falls below theoriginal TCR
.Tools Used
Recommended Mitigation Steps
We can add below check to the
redeemCollateral
function:After adding this, we observe that some tests will fail. This indicates that we are allowing the
TCR
to fall below theoriginal TCR
after redemption at this point, violating the main invariants.Assessed type
Error