Navigating to H-08 from the previous contest we can see that the OperatorDelegator::completeQueuedWithdrawal function in the Renzo protocol is designed to finalize withdrawals from EigenLayer sometimes utilizes accumulated ERC20 tokens to fill the ERC20 withdrawal buffer. However, this function fails in the previous codebase when it tries to call depositQueue::fillERC20withdrawBuffer due to the restrictive onlyRestakeManager modifier, which only allows the RestakeManager contract to access it as seen here. As a result, the completeQueuedWithdrawal function reverts, causing a persistent denial of service (DOS) and preventing admins from retrieving funds from EigenLayer, leading to fund losses for the protocol and users.
Now to resolve this, protocol have passed on this pull request which sufficiently mitigates the issue, cause now the onlyRestakeManager modifier has been removed from the fillERC20withdrawBuffer, which ensures that no DOS would occur on calls to this function, i.e
Lines of code
Vulnerability details
See:
Navigating to H-08 from the previous contest we can see that the
OperatorDelegator::completeQueuedWithdrawal
function in the Renzo protocol is designed to finalize withdrawals from EigenLayer sometimes utilizes accumulated ERC20 tokens to fill the ERC20 withdrawal buffer. However, this function fails in the previous codebase when it tries to calldepositQueue::fillERC20withdrawBuffer
due to the restrictiveonlyRestakeManager
modifier, which only allows the RestakeManager contract to access it as seen here. As a result, thecompleteQueuedWithdrawal
function reverts, causing a persistent denial of service (DOS) and preventing admins from retrieving funds from EigenLayer, leading to fund losses for the protocol and users.Now to resolve this, protocol have passed on this pull request which sufficiently mitigates the issue, cause now the
onlyRestakeManager
modifier has been removed from thefillERC20withdrawBuffer
, which ensures that no DOS would occur on calls to this function, i.e