Several solidity/random-beacon contracts use try-catch blocks as part of their business logic. However, the EVM has a call stack depth limit equal to 1024. A third-party contract can leverage this limitation and force the try-catch-ed calls to revert unconditionally, by using recursion and letting those calls be executed at depth 1025. In such a case, the control flow is passed to the catch clauses which may lead to undesired side effects. Possibly affected contracts/libraries are:
RandomBeacon
BeaconDkg
This issue is about inspecting the existing try-catch blocks and fixing them in case they are prone to the aforementioned problem. A possible fix is requiring that the caller is an EOA using the following check:
require(msg.sender == tx.origin, "Not EOA");
Existing deployments of the solidity/random-beacon contracts have to be upgraded once the random beacon becomes operable and starts creating groups.
Several
solidity/random-beaconcontracts usetry-catchblocks as part of their business logic. However, the EVM has a call stack depth limit equal to 1024. A third-party contract can leverage this limitation and force thetry-catch-ed calls to revert unconditionally, by using recursion and letting those calls be executed at depth 1025. In such a case, the control flow is passed to thecatchclauses which may lead to undesired side effects. Possibly affected contracts/libraries are:RandomBeaconBeaconDkgThis issue is about inspecting the existing
try-catchblocks and fixing them in case they are prone to the aforementioned problem. A possible fix is requiring that the caller is an EOA using the following check:Existing deployments of the
solidity/random-beaconcontracts have to be upgraded once the random beacon becomes operable and starts creating groups.Note: A similar problem was already fixed in the
WalletRegistrycontract living in thesolidity/ecdsapackage: https://github.com/keep-network/keep-core/pull/3756