⛽Gas limit check is inaccurate, leading to an operator being able to fail a job intentionally

Holograph Contest finding by 0xA5DF, Trust and V_B

There is a check to verify that there is enough gas left to execute the HolographBridge.bridgeInRequest() function with the gas limit set by the user. However, due to the EVM's gas forwarding limitation (1/64 rule), the actual amount of gas left during the call may be less than the specified gas limit.

Suppose the gas limit specified by the user is 1,000,000 gas.

According to the vulnerability:

• The check ensures that there is at least the specified gas limit (1,000,000 gas) plus any amount of gas spent before reaching the bridgeInRequest() call.

• However, due to the 1/64 rule, only 63/64 of the remaining gas will be dedicated to an external function call.

Now, let's consider a scenario where the remaining gas before the bridgeInRequest() call is 1,000,000 gas:

• Maximum gas that can be forwarded (considering the 1/64 rule): (1,000,000 * 63) / 64 = 984,375 gas

In this case, the gas check would pass because the remaining gas (1,000,000) is greater than the specified gas limit (1,000,000).

However, during the execution of the transaction, when the bridgeInRequest() function is called, only 984,375 gas will be available due to the EVM's gas forwarding limitation. This means that the function may run out of gas and fail, even though the initial gas check passed.

As a result, the job fails, and the owner of the bridged token loses access to the token.

To mitigate this vulnerability, you can modify the required amount of gas left before the bridgeInRequest() call. One possible mitigation is to multiply the required gas by 32/30, considering the 1/64 rule and adding a margin of safety:

require(
    gasleft() >= (gasLimit + gasSpentBeforeCall) * 32 / 30,
    "Insufficient gas to execute bridgeInRequest()"
);

By adjusting the gas check in this way, you can ensure that enough gas is available for the bridgeInRequest() call, considering the EVM's gas forwarding limitation and providing an additional safety margin.

Implementing this mitigation is crucial to prevent job failures and the loss of access to bridged tokens.