As i already pointed in another report, to,avoid user NFT being stuck inside the SnMessaging contract, we should ensure that user send enough msg.value to cover:
Registration of the msgHash on ethereum storage by snMessaging.
The call of the L1HandlerTransaction by the sequencer on Starknet.
Recommended mitigation greatly address this issue, however there is a MAX_L1_MSG_FEE constant inside SnMessaging contract, to ensure msg.value sent does not exceed this constant see: https://github.com/starkware-libs/cairo-lang/blob/0e4dab8a6065d80d1c726394f5d9d23cb451706a/src/starkware/starknet/solidity/StarknetMessaging.sol#L29-L33, And the Bridge.cairo contract fails to check this inside depositTokens() function.
Because there is no check to ensure msg.value does not exceed the MAX_L1_MSG_FEE, if an user send a transaction with a msg.value that exceed the max fee, the transaction will revert.
To illustrate i wrote a test that revert because we send a value exceeding the max fee. It erevert with MAX_L1_MSG_FEE_EXCEEDED. Copy and paste inside Bridge.t.sol and run it with: forge test --mt test_MAXFEEEXCEEDED -vv
Function call will revert when the MAX_L1_MSG_FEE is exceeded
Manual review
There is a getMaxL1MsgFee() function inside SnMessaging, call it and get the max fee, then check the msg.value against it to ensure it does not exceed before sending the tx. See: https://github.com/starkware-libs/cairo-lang/blob/0e4dab8a6065d80d1c726394f5d9d23cb451706a/src/starkware/starknet/solidity/StarknetMessaging.sol#L31
Please, do not suppose impacts, think about the real impact of the bug and check the CodeHawks documentation to confirm: https://docs.codehawks.com/hawks-auditors/how-to-determine-a-finding-validity A PoC always helps to understand the real impact possible.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.