Trove owners inside a batch are able to manipulate the value of
batchDebtShares by repaying small amounts of debt. As a consequence, the
batch's debt is reduced leaving the amount of shares constant. This
misalignment then impacts when new troves are opened, granting them more
debt shares.
Shares of a batch are updated inside _updateBatchShares when a trove of the
batch is touched. Upon debt decrease, shares are updated as follows:
Making small debt decreases to a trove, leads to batchDebtSharesDelta being
zero for non-zero debt decreases (rounds down). Then, when a new trove is
opened in the same batch more debt shares are assigned to that trove. This
happens because the batchDebt decreased but the batch shares remained
constant after the manipulation:
// To avoid rebasing issues, let’s make sure the ratio debt / shares is not too high
_requireBelowMaxSharesRatio(currentBatchDebtShares, _batchDebt,
_checkBatchSharesRatio);
batchDebtSharesDelta = currentBatchDebtShares * debtIncrease / _batchDebt;
}
Troves[_troveId].batchDebtShares += batchDebtSharesDelta;
batches[_batchAddress].debt = _batchDebt + debtIncrease;
batches[_batchAddress].totalDebtShares = currentBatchDebtShares + batchDebtSharesDelta;
This issue is considered to have low likelihood since the attacker requires to
spend resources to considerably imbalance the share calculation. However,
the likelihood increases for networks that are uncongested or have low gas
fees. The impact is assessed to be medium as the victim will be entitled with
more debt than they should upon debt redistribution.
Trove owners inside a batch are able to manipulate the value of batchDebtShares by repaying small amounts of debt. As a consequence, the batch's debt is reduced leaving the amount of shares constant. This misalignment then impacts when new troves are opened, granting them more debt shares. Shares of a batch are updated inside _updateBatchShares when a trove of the batch is touched. Upon debt decrease, shares are updated as follows:
Making small debt decreases to a trove, leads to batchDebtSharesDelta being zero for non-zero debt decreases (rounds down). Then, when a new trove is opened in the same batch more debt shares are assigned to that trove. This happens because the batchDebt decreased but the batch shares remained constant after the manipulation:
This issue is considered to have low likelihood since the attacker requires to spend resources to considerably imbalance the share calculation. However, the likelihood increases for networks that are uncongested or have low gas fees. The impact is assessed to be medium as the victim will be entitled with more debt than they should upon debt redistribution.