Platform: Code4rena
Start Date: 13/02/2024
Pot Size: $24,500 USDC
Total HM: 5
Participants: 84
Period: 6 days
Judge: 0xA5DF
Id: 331
League: ETH
Rank: 17/84
Findings: 2
Award: $267.84
🌟 Selected for report: 0
🚀 Solo Findings: 0
🌟 Selected for report: nuthan2x
Also found by: 0x0bserver, AM, CaeraDenoir, DanielArmstrong, JrNet, Kirkeelee, KmanOfficial, Krace, Limbooo, Meera, SovaSlava, SpicyMeatball, TheSavageTeddy, agadzhalov, aslanbek, atoko, csanuragjain, d3e4, imare, jesjupyter, juancito, kartik_giri_47538, kutugu, max10afternoon, offside0011, pkqs90, turvy_fuzz, xchen1130, zhaojohnson, ziyou-
25.7286 USDC - $25.73
There is an out of bounds index problem if the distributableERC20s array gets updated and the length increases while a distribution is ongoing.
The setDistributableERC20s function does not check if the LockedForDistribution boolean value. In case a distribution is in progress and the distributableERC20s array increases in length, the distribute function will try to access a erc20EntitlementPerUnit index that is out of bounds.
This is due to the index being determined by the current distributableERC20s array length, while the erc20EntitlementPerUnit length is fixed to the distributableERC20s length when _beginDistribution is called.
I would consider it's impact to be medium. Even if it could be fixed by reverting the distributableERC20s changes, the distribution could get delayed until an admin comes in to fix it. It could also be triggered intentionally by anyone since the distribute function itself has no access control, so anyone can frontrun the distributableERC20s change to maliciously impact the distribution.
VSCode
The setDistributableERC20s function could have a check to prevent it being called when a distribution is in progress.
Other
#0 - c4-pre-sort
2024-02-20T05:53:22Z
0xRobocop marked the issue as duplicate of #260
#1 - c4-judge
2024-03-04T15:29:30Z
0xA5DF marked the issue as satisfactory
#2 - c4-judge
2024-03-08T15:13:03Z
0xA5DF changed the severity to 3 (High Risk)
#3 - c4-judge
2024-03-08T15:26:19Z
0xA5DF changed the severity to 2 (Med Risk)
🌟 Selected for report: SpicyMeatball
Also found by: BowTiedOriole, Breeje, CaeraDenoir, JohnSmith, Krace, Meera, PumpkingWok, SovaSlava, SpicyMeatball, d3e4, juancito, kutugu, nuthan2x, rokinot, rouhsamad, web3pwn
242.1143 USDC - $242.11
In the LiquidInfrastructureERC20.sol contract theres a flaw that could render the withdrawFromManagedNFTs function useless. This is due to nextWithdrawal being higher than ManagedNFTs.length.
The releaseManagedNFTs function does not check that the nextWithdrawal variable is lower or equal to ManagedNFTs.length.
If nextWithdrawal ends up being higher than ManagedNFTs.length there is no way to set nextWithdrawal back to zero.
The impact on the protocol would be medium because even though it is a extremely niche case, it would need an admin action in order to make the contract work again. This is due to the inhability to withdraw the ERC20
tokens from the NFTs until the nextWithdrawal variable is set to zero again.
VSCode
Make the releaseManagedNFTs function reset the nextWithdrawal to zero if the value is higher than the new length of ManagedNFTs.
Other
#0 - c4-pre-sort
2024-02-22T07:41:11Z
0xRobocop marked the issue as duplicate of #130
#1 - c4-judge
2024-03-03T13:04:32Z
0xA5DF marked the issue as satisfactory