Tadle
Tadle
DeFi
30,000 USDC
View results
Previous Next
Submission Details
Severity: high
Valid

[H-2] `SystemConfig::updateReferrerInfo` saves the information incorrectly!

nilay27

Description:

According to the natspec of updateReferrerInfo() the function is not supposed to be called by the referrer, so it means the person referred has to call it and save the referral information for their corresponding address.

However this is not how the code is saving the information!

Code snippet:
https://github.com/Cyfrin/2024-08-tadle/blob/main/src/core/SystemConfig.sol#L69-L72

// @audit it should be saved for _msgSender hence the mapping should be saved to msg.sender
// as they are updating their referrer information
ReferralInfo storage referralInfo = referralInfoMap[_referrer];
referralInfo.referrer = _referrer;
referralInfo.referrerRate = _referrerRate;
referralInfo.authorityRate = _authorityRate;
​
/**
event UpdateReferrerInfo(
address indexed authorityAddress, // authority is supposed to call it on behalf of referrer
address indexed referrerAddress,
uint256 referrerRate,
uint256 authorityRate
);
*/
​
emit UpdateReferrerInfo(
msg.sender,
_referrer,
_referrerRate,
_authorityRate
);

The fact that referralinformation needs to be saved for message sender, can further be concluded from the fact that
in PreMarkets::createTaker() we have

ReferralInfo memory referralInfo = systemConfig.getReferralInfo(
_msgSender() // referral info fetched for message sender i.e authority but is not saved that way in the contract
);
​

Impact:

The user who was referred and had been given authorityRate by the referrer will not be able to take advantage of it to earn back referral fees.

As the ReferralInfo memory referralInfo = systemConfig.getReferralInfo(msgSender) will most likely return empty struct, the referral address will be 0, thus the platform fee will not be refunded to the user or the referrer

in _updateReferralBonus we have

unction _updateReferralBonus(
uint256 platformFee,
uint256 depositAmount,
address stockAddr,
MakerInfo storage makerInfo,
ReferralInfo memory referralInfo,
ITokenManager tokenManager
) internal returns (uint256 remainingPlatformFee) {
if (referralInfo.referrer == address(0x0)) {
remainingPlatformFee = platformFee;
}

Recommended Mitigation:

- ReferralInfo storage referralInfo = referralInfoMap[_referrer];
+ ReferralInfo storage referralInfo = referralInfoMap[_msgSender()];
referralInfo.referrer = _referrer;
referralInfo.referrerRate = _referrerRate;
referralInfo.authorityRate = _authorityRate;
Updates

Lead Judging Commences

0xnevi Lead Judge 10 months ago
Submission Judgement Published
Validated
Assigned finding tags:

finding-SystemConfig-updateReferrerInfo-msgSender

Valid high severity. There are two impacts here due to the wrong setting of the `refferalInfoMap` mapping. 1. Wrong refferal info is always set, so the refferal will always be delegated to the refferer address instead of the caller 2. Anybody can arbitrarily change the referrer and referrer rate of any user, resulting in gaming of the refferal system I prefer #1500 description the most, be cause it seems to be the only issue although without a poc to fully describe all of the possible impacts

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.