Due to a lack of checks in SDPoolSecondary.withdraw(), a malicious user can populate queuedLockUpdates by repeatedly calling the withdraw() function, resulting in a Out of Gas error. Which means reward distribution on the L2 chain will not be possible.
A malicious user can repeatedly call SDPoolSecondary.withdraw() to populate the queuedLockUpdates array:
Due to the array being populated, every time the Keeper, which is an automated entity, sends an update, this update will revert due to being Out of Gas, effectively bricking communication from L2 -> L1.
This attack does not cost a lot due to the execution costs on Arbitrum/Optimism being extremely low. This attack is especially very easy to execute on Optimism due to their low gas block limit.
I wrote this PoC:
As the test finished(takes a few minutes), the traces show(I used hardhat-tracer to follow the traces) :
Communication between L2 -> L1 is bricked, which means updates will not be possible, which means core functionality of this project is broken. Stake.link won't be able to function as it's supposed to. Furthermore, changes in assets of users on the L2 will not be reflected on the L1, potentially causing loss of funds.
Hardhat
Allow a user to make one withdraw per update period or don't allow the user to specify the amount to withdraw, let the user withdraw the maximum amount that the user can withdraw at that moment.
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.