Lack of validation to validate if the correct reserve tokens were minted on the reserve

[code423n4]

Lines of code

https://github.com/code-423n4/2023-05-juicebox/blob/main/juice-buyback/contracts/JBXBuybackDelegate.sol#L337-L345

Vulnerability details

Impact

Break the internal accounting if the number of minted reserved tokens is incorrectly

Proof of Concept

The _reservedToken is calculated by substracting the _amountReceived - _nonReservedToken, and _nonReservedToken is calculated using the below formula, which is the exact same formula used in the controller.mintTokensOf() to determine the value of beneficiaryTokenCount.

uint256 _nonReservedToken = PRBMath.mulDiv(
    _amountReceived, JBConstants.MAX_RESERVED_RATE - _reservedRate, JBConstants.MAX_RESERVED_RATE
);

And finally, the amount calculated for the beneficiaryTokenCount is used to mint the reservedTokens, that implies that the mint was made with the same formula used to calculate the value of the _nonReservedToken in the JBXBuybackDelegate contract

In summary, the minted of reservedTokens in the controller.burnTokensOf() function uses the exact same mathematical formula that is used to calculate the amount of _nonReservedToken.

That breaks the assumption made on the comment that the reserve will have the reservedTokens, it will not, it will have the equivalent of the _nonReservedToken

Tools Used

Manual Audit

Recommended Mitigation Steps

• Make sure to capture the returned value by the comptroller.mintTokensOf() function which is an uint representing the number of tokens received by the beneficiary.
• Use the returned value to compare it agains the _reservedToken variable, and if they are not equals that means that an incorrect amount of reserve tokens were minted to the reserve

Assessed type

Math

[c4-pre-sort]

dmvt marked the issue as low quality report

[dmvt]

Warden fails to describe the impact of this on the protocol

[c4-judge]

dmvt marked the issue as unsatisfactory: Insufficient quality