An incorrect formula in the calculation of the remainingAmount
and totalUsedAmount
variables in the PreMarkets::abortAskOffer
function causes the makerRefundAmount
sent to the Maker to be inaccurate. This leads to improper refunds, potentially resulting in zero or incorrect refunds being issued.
The vulnerability exists in the PreMarkets::abortAskOffer
function, where both remainingAmount
and totalUsedAmount
are calculated using the same formula, even though they are intended to represent opposite values.
Total Used Amount Calculation:
Remaining Amount Calculation:
The above formula is calculating the usedAmount, not the remainingAmount
. remainingAmount is calculated as:
The correct thing is done in OfferLibraries::getRefundAmount
Both remainingAmount
and totalUsedAmount
are calculated using the same formula, despite being intended to represent different values.
As a result, they end up being the same value, which then leads to the transferAmount
and totalDepositAmount
being calculated as the same value.
Transfer Amount Calculation:
Total Deposit Amount Calculation:
Since remainingAmount
and totalUsedAmount
are incorrectly calculated to be the same, transferAmount
and totalDepositAmount
also end up being the same, leading to makerRefundAmount
being zero or another incorrect value depending on the rounding direction.
This leads to incorrect or zero refunds to the Maker, which is problematic as it may result in financial losses or unintended reverts.
Due to the incorrect formula, the protocol consistently miscalculates the refund amounts, potentially leading to zero refunds or incorrect token amounts being returned to the Maker when they abort. This could erode user trust and result in financial discrepancies within the protocol.
Manual analysis
Correct the Calculation Formulas:
Ensure that the formulas used to calculate remainingAmount
and totalUsedAmount
are distinct and correctly reflect their intended values. This will prevent them from being the same and will ensure accurate refunds to Makers.
Review the Logic for Refund Calculations:
Consider revisiting the refund logic to ensure that rounding errors and similar issues do not lead to incorrect refunds. Testing with various rounding methods can help in identifying potential edge cases that may need addressing.
Valid high, for cancelled offers, the unused collateral should be returned back to the maker. The `remainingAmount` is calculated wrongly with regards to usedPoints instead of unused points. Note: See comments under 826 and 907 for invalidation reasons
Valid high, for cancelled offers, the unused collateral should be returned back to the maker. The `remainingAmount` is calculated wrongly with regards to usedPoints instead of unused points. Note: See comments under 826 and 907 for invalidation reasons
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.