DatingDapp
AI First Flight #6
Beginner FriendlyFoundrySolidityNFT
EXP
View results
Previous Next
Submission Details
Severity: high
Valid

`LikeRegistry::matchRewards` keeps the state variable `LikeRegistry::totalFees` at `0`

datadata

[M-2] LikeRegistry::matchRewards keeps the state variable LikeRegistry::totalFees at 0

Description

Function LikeRegistry::matchRewards updates var LikeRegistry::totalFees, but it does so with faulty data by pulling from the mapping LikeRegistry::userBalances, whose entries never change from the default 0.

In contract LikeRegistry:

function matchRewards(address from, address to) internal {
@> uint256 matchUserOne = userBalances[from];
@> uint256 matchUserTwo = userBalances[to];
userBalances[from] = 0;
userBalances[to] = 0;
​
@> uint256 totalRewards = matchUserOne + matchUserTwo;
@> uint256 matchingFees = (totalRewards * FIXEDFEE) / 100;
@> uint256 rewards = totalRewards - matchingFees;
@> totalFees += matchingFees;
...
(bool success, ) = payable(address(multiSigWallet)).call{
@> value: rewards
}("");

Risk

Likelihood:
This is guaranteed to happen any time matchRewards is called.

Impact:
The impact is that this portion of matchRewards effectively does nothing, because it is grabbing 0 from the mapping userBalances to define matchUserOne and matchUserTwo, resetting entries in userBalances to 0, defining totalRewards as 0 + 0, which equals 0, defining matchingFees as (0 * FIXEDFEE) / 100, which equals 0, defining rewards as 0 - 0, which equals 0, and then incrementing totalFees by 0, then transfering a value of 0 to the newly created contract multiSigWallet.

Proof of Concept

Using our added getter function LikeRegistry::getTotalFees, and our modifier that mints profiles for user1 and user2, we see in this function that state variable likeRegistry:totalFees stays at 0 before and after two users mutually like each other, which should call likeRegistry::matchRewards, which should be updating totalFees.

function testMutualLikesDoNotIncreaseTotalFees()
public
mintProfilesUser1AndUser2
{
// ARRANGE
uint256 totalFeesBefore = likeRegistry.getTotalFees();
console.log("totalFees before: ", totalFeesBefore);
​
// ACT
vm.prank(user1);
likeRegistry.likeUser{value: s_feeAmount}(user2);
vm.prank(user2);
likeRegistry.likeUser{value: s_feeAmount}(user1);
​
// ASSERT
uint256 totalFeesAfter = likeRegistry.getTotalFees();
console.log("totalFees after: ", totalFeesAfter);
assertEq(totalFeesBefore, totalFeesAfter);
}

Recommended Mitigation

We recommend that LikeRegistry::likeUser is updated to added non-zero values to the entries in the mapping LikeRegistry::userBalances so that matchRewards accesses non-zero values to indeed match the rewards. See our finding M-1 for more information.

We recommend that the function LikeRegistry::likeUser updates msg.sender's entry in userBalances by adding msg.value to it.

function likeUser(address liked) external payable {
...
likes[msg.sender][liked] = true;
+ userBalances[msg.sender] += msg.value;
emit Liked(msg.sender, liked);
...
}
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge 13 days ago
Submission Judgement Published
Validated
Assigned finding tags:

[H-01] After the user calls the `likeUser` function, the userBalance does not increase by the corresponding value.

## Description User A calls `likeUser` and sends `value > 1` ETH. According to the design of DatingDapp, the amount for user A should be accumulated by `userBalances`. Otherwise, in the subsequent calculations, the balance for each user will be 0. ## Vulnerability Details When User A calls `likeUser`, the accumulation of `userBalances` is not performed. ```solidity function likeUser( address liked ) external payable { require(msg.value >= 1 ether, "Must send at least 1 ETH"); require(!likes[msg.sender][liked], "Already liked"); require(msg.sender != liked, "Cannot like yourself"); require(profileNFT.profileToToken(msg.sender) != 0, "Must have a profile NFT"); require(profileNFT.profileToToken(liked) != 0, "Liked user must have a profile NFT"); likes[msg.sender][liked] = true; emit Liked(msg.sender, liked); // Check if mutual like if (likes[liked][msg.sender]) { matches[msg.sender].push(liked); matches[liked].push(msg.sender); emit Matched(msg.sender, liked); matchRewards(liked, msg.sender); } } ``` This will result in `totalRewards` always being 0, affecting all subsequent calculations: ```solidity uint256 totalRewards = matchUserOne + matchUserTwo; uint256 matchingFees = (totalRewards * FIXEDFEE ) / 100; uint256 rewards = totalRewards - matchingFees; totalFees += matchingFees; ``` ## POC ```solidity function testUserBalanceshouldIncreaseAfterLike() public { vm.prank(user1); likeRegistry.likeUser{value: 20 ether}(user2); assertEq(likeRegistry.userBalances(user1), 20 ether, "User1 balance should be 20 ether"); } ``` Then we will get an error: ```shell [FAIL: User1 balance should be 20 ether: 0 != 20000000000000000000] ``` ## Impact - Users will be unable to receive rewards. - The contract owner will also be unable to withdraw ETH from the contract. ## Recommendations Add processing for `userBalances` in the `likeUser` function: ```diff function likeUser( address liked ) external payable { require(msg.value >= 1 ether, "Must send at least 1 ETH"); require(!likes[msg.sender][liked], "Already liked"); require(msg.sender != liked, "Cannot like yourself"); require(profileNFT.profileToToken(msg.sender) != 0, "Must have a profile NFT"); require(profileNFT.profileToToken(liked) != 0, "Liked user must have a profile NFT"); likes[msg.sender][liked] = true; + userBalances[msg.sender] += msg.value; emit Liked(msg.sender, liked); [...] } ```

Support

FAQs

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

Give us feedback!