contracts/core/ccip/SDLPoolCCIPControllerSecondary.sol#58-60
contracts/core/ccip/SDLPoolCCIPControllerSecondary.sol#157
Possibility of a read reentrancy in the checkUpkeep function of the SDLPoolCCIPControllerSecondary contract in lines 58-60.
In Ethereum, a view or pure function is considered "read-only." This means that, in theory, these functions should not modify the contract's state. However, there is a specific vulnerability called "read reentrancy,"
read reentrancy, which involves a function that is supposed to only read data from the contract, somehow allowing a read of outdated data if called while the contract's state is being modified by another function.
In this case, the warning indicates that the checkUpkeep function is reading the state of the shouldUpdate variable, and that variable is modified after an external call elsewhere in the contract (shouldUpdate = true in SDLPoolCCIPControllerSecondary.sol#157).
The concern is that if another function or contract calls checkUpkeep while the state is in an updating process (when shouldUpdate is changed to true), it could access an outdated state of the shouldUpdate variable. This can lead to unexpected behaviors or incorrect results if they rely on the updated value of shouldUpdate.
Outdated or incorrect information
Audit Wizard, Slither, Chat GPT, Manual Rerview
The recommendation to address this potential read reentrancy vulnerability is to ensure that the checkUpkeep function accesses only data that is in a consistent state, regardless of whether other operations are ongoing in the contract. This can be achieved by implementing locks or checks that ensure the checkUpkeep function does not execute while changes to the state that may affect data reading are being made.
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.