Platform: Code4rena
Start Date: 28/11/2022
Pot Size: $192,500 USDC
Total HM: 33
Participants: 106
Period: 11 days
Judge: LSDan
Total Solo HM: 15
Id: 186
League: ETH
Rank: 41/106
Findings: 2
Award: $292.01
🌟 Selected for report: 0
🚀 Solo Findings: 0
🌟 Selected for report: Englave
Also found by: 9svR6w, Jeiwan, Josiah, Lambda, RaymondFam, Trust, csanuragjain, kaliberpoziomka8552, minhquanym, unforgiven
286.3766 USDC - $286.38
When the admin calls removeFeeder()
, it will internally call _removeFeeder()
that will have the feeder removed from feeders
before getting its UPDATE_ROLE
revoked. In the midst of doing this, the protocol forgets to update index
of feederPositionMap
belonging to the last feeder (e.g. feeder X
for reference) of feeders
who has now taken over the position of the removed feeder. This could lead to function error when eventually feederX
will need to be removed too.
function _removeFeeder(address _feeder) internal onlyWhenFeederExisted(_feeder) { uint8 feederIndex = feederPositionMap[_feeder].index; if (feederIndex >= 0 && feeders[feederIndex] == _feeder) { feeders[feederIndex] = feeders[feeders.length - 1]; feeders.pop(); } delete feederPositionMap[_feeder]; revokeRole(UPDATER_ROLE, _feeder); emit FeederRemoved(_feeder); }
From the code block above, if (feederIndex >= 0 && feeders[feederIndex] == _feeder)
will revert when attempting to remove feederX
because you are now accessing an out of bound element in feeders
Manual
It is recommended updating correctly the index
of feederPositionMap
belonging to feederX
that has replaced the removed feeder.
#0 - c4-judge
2022-12-20T17:39:19Z
dmvt marked the issue as duplicate of #47
#1 - c4-judge
2023-01-09T15:35:28Z
dmvt changed the severity to 3 (High Risk)
#2 - c4-judge
2023-01-23T15:47:16Z
dmvt marked the issue as satisfactory