Part 2
Zaros
PerpetualsDEXFoundrySolidity
70,000 USDC
View results
Previous Next
Submission Details
Severity: high
Valid

Incorrect credit capacity check in `redeem()`

tigerfrake

Summary

The redeem function in the VaultRouterBranch contract contains a flawed check that determines whether the change in credit capacity exceeds the locked credit capacity before the state transition.

Vulnerability Details

The following comment is given:

// if the credit capacity delta is greater than the locked credit capacity before the state transition, revert

However, the actual check is performed as follows:

if (
>> ctx.creditCapacityBeforeRedeemUsdX18.sub(vault.getTotalCreditCapacityUsd()).lte(
ctx.lockedCreditCapacityBeforeRedeemUsdX18.intoSD59x18()
)
) {
revert Errors.NotEnoughUnlockedCreditCapacity();
}

The current implementation uses a less-than-or-equal-to comparison, which may allow transactions that lead to insufficient unlocked credit capacity.

Impact

Allowing the transaction to proceed under the current logic could lead to scenarios where the unlocked credit capacity is insufficient, resulting in the inability to fulfill future withdrawal requests or other operations that depend on available credit.

Tools Used

Manual Review

Recommendations

Change the comparison in the check from less-than-or-equal-to (lte) to greater-than (gt):

if (
- ctx.creditCapacityBeforeRedeemUsdX18.sub(vault.getTotalCreditCapacityUsd()).lte(
+ ctx.creditCapacityBeforeRedeemUsdX18.sub(vault.getTotalCreditCapacityUsd()).gt(
ctx.lockedCreditCapacityBeforeRedeemUsdX18.intoSD59x18()
)
) {
revert Errors.NotEnoughUnlockedCreditCapacity();
}
Updates

Lead Judging Commences

inallhonesty Lead Judge 6 months ago
Submission Judgement Published
Validated
Assigned finding tags:

The check in VaultRouterBranch::redeem should be comparing remaining capacity against required locked capacity not delta against locked capacity

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.