Account Abstraction Schnorr MultiSig - InFlux Technologies

The EntryPoint contract handles error messages from paymaster calls without imposing size limits. This occurs in two critical locations where external calls to paymaster contracts are made: _validatePaymasterPrepayment and _handlePostOp. First instance in _validatePaymasterPrepayment:

function _validatePaymasterPrepayment(
    uint256 opIndex,
    UserOperation calldata op,
    UserOpInfo memory opInfo,
    uint256 requiredPreFund,
    uint256 gasUsedByValidateAccountPrepayment
) internal returns (bytes memory context, uint256 validationData) {
    // .... // 
    try IPaymaster(paymaster).validatePaymasterUserOp{gas: gas}(op, opInfo.userOpHash, requiredPreFund)
        returns (bytes memory _context, uint256 _validationData) {
            context = _context;
            validationData = _validationData;
    } catch Error(string memory revertReason) {
        revert FailedOp(opIndex, string.concat("AA33 reverted: ", revertReason));
    }
}

Second instance in _handlePostOp:

function _handlePostOp(
    uint256 opIndex,
    IPaymaster.PostOpMode mode,
    UserOpInfo memory opInfo,
    bytes memory context,
    uint256 actualGas
) private returns (uint256 actualGasCost) {
    // ... //
    try IPaymaster(paymaster).postOp{gas: mUserOp.verificationGasLimit}(mode, context, actualGasCost)
    {} catch Error(string memory reason) {
        revert FailedOp(opIndex, string.concat("AA50 postOp reverted: ", reason));
    }
}

While the contract defines REVERT_REASON_MAX_LEN = 2048, this limit is not enforced when handling these paymaster error messages.

Report as informational as it's paymaster handling but there are several impacts here :

• Gas consumption becomes unpredictable when copying large error messages to memory

• Malicious paymasters can force excessive gas consumption through large error messages

• Bundle execution can fail unexpectedly due to out-of-gas conditions

It is recommended to implement error message length limits using the existing REVERT_REASON_MAX_LEN constant.

NOT APPLICABLE: Non concerning because the current deployed files does not use the affected code.

The BasePaymaster contract lacks interface validation for the _entryPoint parameter in its constructor. The current implementation directly sets the EntryPoint address without verifying if it implements a matching IEntryPoint interface.

constructor(IEntryPoint _entryPoint, address _owner) Ownable(_owner) {

	//E @tocheck missing sanity check for _entryPoint

	setEntryPoint(_entryPoint);
}

It is recommended to implement the same mechanism as it is done in eth-infinitism development branch repository which includes proper validation with an interface to be implemented:

constructor(IEntryPoint _entryPoint) Ownable(msg.sender) {

	_validateEntryPointInterface(_entryPoint);
	
	entryPoint = _entryPoint;

}

function _validateEntryPointInterface(IEntryPoint _entryPoint) internal virtual {
   require(IERC165(address(_entryPoint)).supportsInterface(type(IEntryPoint).interfaceId), "IEntryPoint interface mismatch");
}

ACKNOWLEDGED: An on chain version of this file will be used instead of the one in the repository, but the project does not use the affected code.

The _validateAccountPrepayment function in EntryPoint.sol fails to verify the existence of code at the sender's address when initCode is empty. While the function deploys new accounts when initCode is provided, it assumes pre-existing accounts are already deployed without verification.

function _validateAccountPrepayment(
		uint256 opIndex,
		UserOperation calldata op,
		UserOpInfo memory opInfo,
		uint256 requiredPrefund
) internal returns (uint256 gasUsedByValidateAccountPrepayment, uint256 validationData) {
		unchecked {
			MemoryUserOp memory mUserOp = opInfo.mUserOp;
			address sender = mUserOp.sender;
			_createSenderIfNeeded(opIndex, opInfo, op.initCode);
			// Missing verification of sender.code.length
			try IAccount(sender).validateUserOp{gas: mUserOp.verificationGasLimit}(op,opInfo.userOpHash,missingAccountFunds)
			// ... // 

The issue occurs because the subsequent call to validateUserOp will revert at the EVM level if no code exists at the sender's address. This revert happens before entering the try-catch block, preventing the emission of the expected FailedOp error.

The risk is that Bundlers receive unclear error feedback when processing transactions for non-deployed accounts.

It is recommended to add an explicit deployment check after _createSenderIfNeeded to ensure consistent error handling and provide clear feedback about account deployment status.

ACKNOWLEDGED: An on chain version of this file will be used instead of the one in the repository, but the project does not use the affected code.

The EntryPoint contract contains multiple functions where entire function bodies are wrapped in unchecked blocks, rather than limiting these blocks to specific arithmetic operations that require them. This pattern is observed in critical functions including _validateAccountPrepayment, _validatePaymasterPrepayment, and _execute instances:

function _validateAccountPrepayment(
    uint256 opIndex,
    UserOperation calldata op,
    UserOpInfo memory opInfo,
    uint256 requiredPrefund
) internal returns (uint256 gasUsedByValidateAccountPrepayment, uint256 validationData) {

    unchecked {
        // Entire function body (50+ lines) within unchecked block
        uint256 preGas = gasleft();
        // ... many operations that don't require unchecked math
        gasUsedByValidateAccountPrepayment = preGas - gasleft();
    }

}

function _validatePaymasterPrepayment(
    uint256 opIndex,
    UserOperation calldata op,
    UserOpInfo memory opInfo,
    uint256 requiredPreFund,
    uint256 gasUsedByValidateAccountPrepayment
) internal returns (bytes memory context, uint256 validationData) {
   
    unchecked {
        // Entire function body within unchecked block
        // ... including operations that don't require unchecked math
        paymasterInfo.deposit = uint112(deposit - requiredPreFund);
    }

}

Impacts:

• Reduced code clarity and increased review complexity

• Higher risk of arithmetic overflow/underflow vulnerabilities

It is recommended to restrict unchecked blocks to specific arithmetic operations where overflow/underflow checks are unnecessary.

ACKNOWLEDGED: An on chain version of this file will be used instead of the one in the repository, but the project does not use the affected code.