Shambolic Banana Barbel
High
When L2 to L1 (withdrawal) transactions are sent, the gasLimit and message values are not validated. If they lead to a transaction that cannot be executed on L1 (for example, because the gas required exceeds the block gas limit, or because the message is too long that the memory expansion cost of the calldata exceeds the block gas limit), the funds will be permanently lost.
When sending a withdrawal message from L2 to L1 using L2CrossDomainMessenger.sol, the sendMessage() function takes in a message and gasLimit.
These two values are not validated in any way before taking the user's funds and adding the withdrawal message to the message passer tree.
In the event that the withdrawal transaction cannot be executed on L1 (for example, because the gas required exceeds the block gas limit, or because the message is too long that the memory expansion cost of the calldata exceeds the block gas limit), there is no way to "drop" the transaction and receive a refund on L2. The funds will be permanently stuck.
Note that in the L1 to L2 (deposit) direction, we have a check that ensures that the calldata is of appropriate length for the gas limit specified, and that the gas limit is well under the block gas limit. This ensures the transactions will be executed as expected.
In contract, in the L2 to L1 (withdrawal) direction, there are no checks, the gasLimit value that is passed is completely ignored, and bricked withdrawals are entirely possible.
None
- A user sends a withdrawal transaction that has calldata or L1 execution that will require more gas than the L1 block gas limit.
N/A
The user will unrecoverably lose all funds withdrawn through the bridge.
N/A
Validate that the gasLimit passed is less than the L1 block gas limit, and that the message calldata is of appropriate length for the gas limit specified. If this is not the case, the withdrawal transaction should revert so the user keeps their funds on L2.