Lines of code

Vulnerability details

Impact

When reward.token is set to vault address and native token is used, it is sent out via payable.transfer call. This is unsafe as transfer has hard coded gas budget and can fail when the _account is a smart contract. Such transactions will fail for smart contract users which don’t fit to 2300 gas stipend transfer have.

As claim -> _claim call is the only way to retrieve rewards and Merkle leaf node includes _account, this means that such _accounts will be unable to retrieve rewards at all, having them frozen within the system. Setting severity to high as these reward funds are lost for such users.

Proof of Concept

RewardDistributor._claim performs payable(_account).transfer(_amount) call:

<https://github.com/code-423n4/2022-02-redacted-cartel/blob/main/contracts/RewardDistributor.sol#L181&gt;

Whenever _account is an another contract which either fails to implement the payable fallback function or cumulative gas cost of the function sequence invoked on native token transfer exceeds 2300 gas consumption limit the native tokens sent will be undelivered. This leads to systematic fail of claim and the reward retrieval functionality in such cases.

References

The issues with transfer() are outlined here:

<https://consensys.net/diligence/blog/2019/09/stop-using-soliditys-transfer-now/&gt;

Recommended Mitigation Steps

As claim is nonReentrant, the reentrancy isn’t an issue and transfer() can be replaced.

Using low-level call.value(amount) with the corresponding result check or using the OpenZeppelin Address.sendValue is advised:

<https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/Address.sol#L60&gt;

---

The text was updated successfully, but these errors were encountered:

All reactions