_recipients
, _tokenData
, _saltfun_o
and _numberOfTokens
should all have same length in airDropTokens
#312
Labels
2 (Med Risk)
Assets not at direct risk, but function/availability of the protocol could be impacted or leak value
bug
Something isn't working
duplicate-1384
edited-by-warden
unsatisfactory
does not satisfy C4 submission criteria; not eligible for awards
Lines of code
https://github.com/code-423n4/2023-10-nextgen/blob/main/smart-contracts/MinterContract.sol#L181-L192
Vulnerability details
Impact
No check is being made on the length of the input arrays in the
airDropTokens
function, meaning the caller could get an unexpected behavior from the airdrop function with no warning in case of mistakes in the inputs.We mark this vulnerability as MEDIUM as it could alter the good functioning of the
NextGenCore
contract.Proof of Concept
Let’s have a closer look at the
airDropTokens
function belowIf a function admin calls this function with three arrays as input with, for example,
_recipients.length == 3
,_tokenData.length == 4
,_saltfun_o.length == 4
and_numberOfTokens.length == 4
(this could mean the admin wanted to airdrop to 4 recipients but forgot one of the values in the_recipients
array).In that case, the function will go through fine, airdropping for the 3 recipients given in the
_recipients
array.As the function will not revert in that case, the admin could think that he successfully airdropped for 4 recipients when in fact only 3 received the airdrop.
This is easily fixed so should be prevented.
Tools Used
Manual Review / Visual Studio
Recommended Mitigation Steps
Add a
require
statement to theairDropTokens
function to avoid this situation.The
airDropTokens
function could then look like this:meaning the call will revert if inputs are wrong.
Assessed type
Invalid Validation
The text was updated successfully, but these errors were encountered: