Platform: Code4rena
Start Date: 09/11/2021
Pot Size: $30,000 ETH
Total HM: 6
Participants: 17
Period: 3 days
Judge: pauliax
Total Solo HM: 3
Id: 50
League: ETH
Rank: 6/17
Findings: 3
Award: $756.21
🌟 Selected for report: 1
🚀 Solo Findings: 0
rfa
This function can be used by the beneficiary to update their vested token, however the function is callable by anyone, there is no check if the msg.sender/caller is the correct beneficiary, the only check is https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/token/FSDVesting.sol#L151, but this check is user controllable, therefore malicious actor can call this function to inflate the amount variable to uint256(-1), this can lead to dos, when the correct beneficiary want to update their vested token through https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/token/FSD.sol._createdVesting()
https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/token/FSDVesting.sol#L147
#0 - YunChe404
2021-11-14T11:15:07Z
Change severity to bug risk level 3
#1 - YunChe404
2021-11-14T11:15:36Z
#32
#2 - pauliax
2021-11-17T12:08:09Z
A duplicate of #101
0.007 ETH - $33.11
rfa
When you are reading a value from a storage and using a storage pointer instead of memory, you write directly to the storage instead of the memory. In the https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/network/FSDNetwork.sol#L234 this line is reading membership[msg.sender] with a storage pointer, this means any changes to the user variable, is updating directly to the membership[msg.sender], therefore https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/network/FSDNetwork.sol#L294 this line update, makes it useless since the data already written to the membership[msg.sender]
https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/network/FSDNetwork.sol#L234-L294
https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/network/FSDNetwork.sol#L294 membership[msg.sender] = user;
#0 - pauliax
2021-11-16T23:16:00Z
Great find, valid optimization.
rfa
There is a missing underflow check, which can lead to wrong calculation of the mint amount
https://github.com/code-423n4/2021-11-fairside/blob/main/contracts/token/FSD.sol#L216
When doing substract calculation use the DSMath.sub()
#0 - YunChe404
2021-11-14T11:16:46Z
#36
#1 - pauliax
2021-11-19T11:03:40Z
These lines are equivalent:
getReserveBalance() - bonded address(this).balance.sub(pendingWithdrawals) - bonded
address(this).balance will be increased by msg.value, so the underflow can only happen if eth balance before was less than pendingWithdrawals. I don't this this is a possible scenario, but nevertheless, I am adding this list to the group of others: #71, please read the comment there.