Incorrect check can cause reverts for redemptions

[code423n4]

Lines of code

https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/RedemptionHelper.sol#L126-L128

Vulnerability details

Impact

The function redeemCollateral in RedemptionHelper checks that the caller doesn't have a higher balance than the totalDebt from the chosen _collateral

https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/RedemptionHelper.sol#L126-L128

       totals.totalLUSDSupplyAtStart = getEntireSystemDebt(_collateral);
        // Confirm redeemer's balance is less than total LUSD supply
        assert(lusdToken.balanceOf(_redeemer) <= totals.totalLUSDSupplyAtStart);

However, because the system is multi-collateral, it is possible for:

lusdToken.balanceOf(_redeemer) to be greater than getEntireSystemDebt(_collateral);

This is a mistake in the logic, as the invariant should be checking for all system collaterals

Proof of Concept

Imagine a scenario with two collaterals, one with 10 debt and another with 100
A: 10 debt, you own 0
B: 100 debt, you own 100 (perhaps bought from AMM or minted yourself)

If you tried to redeem the 10 A, you'd get a revert as the check would compare

yourbalance = 100 <= 10

Which will revert.

Additional considerations

This may also create an opportunity to grief a redeemer, if they were holding a lot of the total debt, a marginal donation may be sent in order to trigger a revert.

Recommended Mitigation Steps

Either change the check to ensure that the debt paid is less than the total

Or sum up all of the debts for all collaterals and check against that

[c4-judge]

trust1995 marked the issue as satisfactory

[c4-judge]

trust1995 marked the issue as primary issue

[c4-sponsor]

tess3rac7 marked the issue as sponsor confirmed

[c4-judge]

trust1995 marked issue #381 as primary and marked this issue as a duplicate of 381