[M-3] There is no way to cancel L2 L1 bridge requests

Summary

Unlike the L1 L2 flow, there is no way to cancel L2 L1 messages and receive back your deposited NFT. This could have dangerous impacts like NFTs getting stuck in escrow or getting burnt upon deposit without possibility of recovery.

Vulnerability Details

If a user wants to cancel a request to bridge an NFT from L1 L2, they can call cancelRequest using the nonce of the message sent to L2.

However, what if the user wants to bridge an L2-Native NFT from L2 L1? After doing the deposit on L2, their NFT is taken into escrow by the L2 bridge:

Despite that one cannot cancel L2 L1 messages in the same way provided for L1 L2 messages, there should be some way to cancel the L2 L1 request and receive the NFT back from the L2 bridge contract. If this does not exist, the user has no choice but to withdraw the NFT on L2 and then bridge back to L1, which potentially could not be possible to due some unforeseeable error. This could result in the user's NFT getting stuck in the L2 bridge contract or lost forever if use_deposit_burn_auto = true.

Impact

The NFT in question could get stuck in escrow forever in the L2 bridge contract (freezing of assets). If the user has set use_deposit_burn_auto = true, then the NFT, which is burnt on deposit, cannot be reminted by the user for free if the request ends up failing on L1 side, resulting in a loss of assets. Though this is a high impact by Codehawks rules, the likelihood is hard to predict and potentially depends on the validities of other issues found in this very contest. Since this issue's severity should be measured in isolation and not influenced by the validity of other bugs, low likelihood and therefore medium severity overall makes the most sense.

Tools Used

VSCode

Recommendations

Since there is no way to cancel a message sent to L1, we could mark the message as seen on the L1 side and refuse to process any messages that have been seen before. One option is to add a L1-side cancellation method for L2 L1 messages. This would mark the message we want to cancel as "cancelled" and "seen". The L1 bridge can then refuse to process messages that are marked as cancelled and seen. Such a method would then need to send a message to L2 and transfer/mint the NFT on the L2 side back to the user. This transferring/minting method on the L2 side would be #[l1_handler] only.