Description

In the TToken.redeemFresh() function, the lines that call divScalarByExpTruncate() assign a math error to vars.mathErr, but this error is not checked before it is overwritten by the subsequent math operation:

+            (vars.mathErr, vars.redeemTokens) =
+                divScalarByExpTruncate(redeemAmountIn, Exp({mantissa: vars.exchangeRateMantissa}));
+
+            (vars.mathErr, vars.redeemAmount) =
+                mulScalarTruncate(Exp({mantissa: vars.exchangeRateMantissa}), vars.redeemTokens);
+
+            if (vars.mathErr != MathError.NO_ERROR) {
+                return failOpaque(
+                    Error.MATH_ERROR, FailureInfo.REDEEM_EXCHANGE_AMOUNT_CALCULATION_FAILED, uint256(vars.mathErr)
+                );

As a result, any math error produced during this division could be silently ignored and leads to possible incorrect calculations and unintended behaviors.

Impact

In the case where the caller is malicious, there is no security impact, because this occurs in a branch where redeemTokensIn is zero, and so the first division is used to determine vars.redeemTokens automatically based on on-chain values. In the other branch, at this step in the workflow, vars.redeemTokens can be arbitrarily set by the caller. So, even if a math error occurs here, the impact would only be to allow the caller to arbitrarily set something they can already intentionally do. The token-balance check happens in redeemAllowed, which is called later.

In the case where the caller is not malicious but a third party is malicious, there is still no security impact. This is because a caller that calls this function with a zero redeemTokensIn quantity is already expecting the protocol to maximize the amount of tokens they redeem. So, any amount of actually redeemed tokens less than the maximum they are entitled to, due to an ongoing attack, would likely be better than the amount of tokens they can redeem after the attack completes.

Recommendations

Even though there is no security impact, we recommend exiting with an error if this calculation fails, so that unexpected behavior does not silently occur.

Remediation

This issue has been acknowledged by Takara Lend, and a fix was implemented in commit 571c9790↗.