RealMaushish - Incorrect casting in `SignerValidator.sol`

[sherlock-admin4]

RealMaushish

High

Incorrect casting in SignerValidator.sol

Summary

SignerValidator.sol#Validate() checks one condition in which it ensure that incentive quantity is lower or equal to incentiveID

Vulnerability Detail

SignerValidator.sol#Validate() checks make sure that incentive quantity is lower or equal to incentiveID

 function validate(uint256 boostId, uint256 incentiveId, address claimant, bytes calldata claimData)
        external
        override
        returns (bool)
    {
        if (msg.sender != _validatorCaller) revert BoostError.Unauthorized();

        (BoostClaimData memory claim) = abi.decode(claimData, (BoostClaimData));
        (SignerValidatorInputParams memory validatorData) =
            abi.decode(claim.validatorData, (SignerValidatorInputParams));

        bytes32 hash = hashSignerData(boostId, validatorData.incentiveQuantity, claimant, claim.incentiveData);

        if (uint256(validatorData.incentiveQuantity) <= incentiveId) {
            revert BoostError.InvalidIncentive(validatorData.incentiveQuantity, incentiveId);
        }
        if (!signers[validatorData.signer]) revert BoostError.Unauthorized();

        // Mark the incentive as claimed to prevent replays
        // checks internally if the incentive has already been claimed
        _used.setOrThrow(hash, incentiveId);

        // Return the result of the signature check
        // no need for a sig prefix since it's encoded by the EIP712 lib
        return validatorData.signer.isValidSignatureNow(hash, validatorData.signature);
    }

here lies the issue:

• incentive ID is inherently a uint256 variable which can have at max value uint256.max
• Incentive quantity is inherently a uint8 variable which can have at max valueuint8.max For this comparison incentive quantity gets conversed into a uint256 variable but it doesnot solve the issue as it only add 248 bits of zeros to uint8.max value considering if the quantity was uint8.max According to the sponsor this must not happen:

But clearly there is a lack of check for such design choice

Impact

Users wont be able to claim incentives as the quantity will be maximum which will make the check revert

Code Snippet

https://github.com/sherlock-audit/2024-06-boost-aa-wallet/blob/main/boost-protocol/packages/evm/contracts/validators/SignerValidator.sol#L50

Tool used

Manual Review

Recommendation

• change the incentive id data set