Submitted by Respx
https://github.com/code-423n4/2022-08-fiatdao/blob/fece3bdb79ccacb501099c24b60312cd0b2e4bb2/contracts/features/Blocklist.sol#L27
https://github.com/code-423n4/2022-08-fiatdao/blob/fece3bdb79ccacb501099c24b60312cd0b2e4bb2/contracts/VotingEscrow.sol#L531
https://github.com/code-423n4/2022-08-fiatdao/blob/fece3bdb79ccacb501099c24b60312cd0b2e4bb2/contracts/VotingEscrow.sol#L637
In the normal flow, an account that is blocked is protected from having its funds locked by a call to forceUndelegate(), as occurs on line 27 of Blocklist.sol.
However, this protection could potentially be circumvented if the value of blocklist is changed to an address which returns True for isBlocked() (as tested in the modifier checkBlocklist()) and if this account was not previously blocked (ie. forceUndelegate() was never called on it).
In this situation, if the account has delegated, its tokens will be rendered irretrievable.
The blocked account would not be able to call wthdraw() successfully because of the check on line 531.
The blocked account would not be able to call quitLock() successfully because of the check on line 637.
The blocked account would not be able to call delegate() to undelegate and thereby allow it to make these calls because delegate() uses the checkBlocklist modifier.
Blocklist has no unblock functionality, so the only way to release the tokens would be through a redeployment of Blocklist.
This situation is most likely to occur as an error during a blocklist migration. In that case, it could be mitigated by adding an unblock functionality to the blocklist contract.
lacoop6tu (FIAT DAO) acknowledged
elnilz (FIAT DAO) disagreed with severity and commented:
Justin Goro (judge) decreased severity to Meidum and commented:
IllIllI (warden) reviewed mitigation:
