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.