The antiLambdaConvert
function in the LibConvertData.sol
library is made to decode conversion parameters from a byte array, including a boolean flag decreaseBDV
that indicates whether the bean denominated value (BDV) should be decreased. Albeit, the function hardcodes this boolean to true
, which does not allow for dynamic behavior based on the input data. This inflexibility can lead to incorrect application logic where the decrease of BDV might not be intended.
Here is the sequence of function calls leading to the issue:
ConvertFacet.convert
function is called:
Inside LibConvert.convert
, based on the conversion kind, it calls LibLambdaConvert.antiConvert
:
LibLambdaConvert.antiConvert
then calls LibConvertData.antiLambdaConvert
:
In LibConvertData.antiLambdaConvert
, the boolean decreaseBDV
is hardcoded:
However, the NatSpec comment for antiLambdaConvert
suggests that there should be a boolean to indicate whether to decrease BDV, implying flexibility (true or false). However, the implementation hardcodes this value to true
, which contradicts the suggested flexibility in the NatSpec comment.
Here is the Natspec:
The hardcoded boolean value restricts the flexibility of conversion operations, potentially leading to unintended financial or state changes in the smart contract system. This could affect the correctness of deposit updates and other relevant calculations or conversions. As already shown above, here is the chain of calls affected:
ConvertFacet.convert
in ConvertFacet.sol
calls LibConvert.convert
in LibConvert.sol
which calls LibLambdaConvert.antiConvert
in LibLambdaConvert.sol
which eventually calls LibConvertData.antiLambdaConvert
in LibConvertData.sol
where this bug originates from.
Manual review
Modify the abi.decode
line in LibConvertData.antiLambdaConvert
to include the boolean value from the encoded data:
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.