Summary

For some specific NFTs (there is a mapping in L2 but not in L1), the user's cross-chain NFT will be stuck.

Vulnerability Details

Background:

1. When a new NFT crosses the chain from L1 to L2, the corresponding L2 address mapping is not set, so the corresponding collection_l2 is 0, and the new NFT will be deployed. And update l2_to_l1_addresses.

2. When this kind of NFT crosses the chain from L2 to L1, neither l1Req nor l2Req in the parameters is equal to 0. However, there is no mapping of this kind of NFT in L1, so l1Mapping == 0 and l1Req != 0, so l1Mapping != l1Req, the cross-chain cannot be completed.

Therefore, if there is a new NFT that crosses the chain from L1 to L2, and the user wants to cross the chain from L2 to L1, this cannot be accomplished. This goes against what the documentation says: User: can bridge a NFT from Ethereum to Starknet or from Starknet to Ethereum.

When a user initiates a cross-chain request on L2, it can be executed successfully, and there is no way to cancel the cross-chain request. But the NFT cannot be taken out at L1.

Therefore, NFT will be stuck until the owner manually updates the mapping of L1. In the long-term operation of the project, it is unrealistic for the owner to manually maintain all mappings.

Since funds may be locked and the normal functions of the protocol are affected, the risk is judged to be high. Since there are no harsh conditions, the possibility is H/M. I judge the risk level to be H/M.

Impact

The user's cross-chain NFT will be stuck, and the user cannot freely cross-chain.

Tools Used

manual

Recommendations

It is recommended to modify the mapping check logic and delete redundant checks.