The Starklane::initialize function is responsible for initializing the contract and setting the contract owner to the address provided in the input bytes data. However, the function also attempts to execute two privileged operations, setStarklaneL2Address and setStarklaneL2Selector, immediately after transferring ownership. If the owner parsed from data is not the same as msg.sender, these operations will fail, causing the entire initialize function to revert.
In the Starklane::initialize function, the ownership of the contract is transferred to the owner address specified in the input data. This is done as follows:
The key issue here is that after the _transferOwnership(owner) line, the contract expects the owner to execute the subsequent setStarklaneL2Address and setStarklaneL2Selector operations. However, if owner is not equal to msg.sender, these operations will fail because the caller has no authority at all.
The privileged functions setStarklaneL2Address and setStarklaneL2Selector are both protected by the onlyOwner modifier:
Since the ownership is transferred within the initialize function, any mismatch between msg.sender and the owner parsed from data will cause these function calls to fail, leading to a full reversion of the initialize function.
The Starklane::initialize function will always revert unless the owner specified in the input data is the same as msg.sender.
Manual
To prevent this issue, it is recommended to transfer ownership to msg.sender directly, ensuring that the caller of the initialize function remains the contract owner for subsequent privileged operations.
No real impact. It even prevents to set an invalid owner. Future versions/upgrades are out-of-scope since this function can/will change to do not modify the owner at every upgrades.
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.