ETH Dust Accumulation in createAndInitializePoolIfNecessary

[c4-bot-9]

Lines of code

https://github.com/ronin-chain/katana-v3-contracts/blob/03c80179e04f40d96f06c451ea494bb18f2a58fc/src/periphery/base/PoolInitializer.sol#L15-L35

Vulnerability details

Impact

The createAndInitializePoolIfNecessary function in the PoolInitializer contract is marked as payable, but does not include logic for handling any ETH sent with the transaction. This oversight could result in unintended "dust" ETH becoming trapped in the contract indefinitely. Over time, this could lead to the following impacts:

Proof of Concept

1. In the PoolInitializer contract:

   • createAndInitializePoolIfNecessary is marked payable, allowing it to receive ETH.
   • This function neither uses nor refunds any ETH sent with the transaction, causing any ETH attached to calls to be trapped in the contract.

2. Potential Issues:

   • Trapped ETH: ETH sent to this function remains in the contract without a clear mechanism to withdraw, affecting users and creating “dust” balances.
   • Unintended Accumulation: Repeated calls could accumulate dust ETH balances, which could be at risk if an attacker gains unauthorized access to withdraw from the contract.

Tools Used

Manual code review.

Recommended Mitigation Steps

Add a mechanism to refund any unused ETH at the end of the function. For instance, implementing a call to the refundETH() function from the PeripheryPayments contract, if available, would prevent ETH from being trapped in the contract and ensure user funds are safely returned. Alternatively, adding an address(0).call{value: msg.value}(""); call would return any attached ETH back to the sender if unutilized.

Assessed type

Payable

[nevillehuang]

Would require user error, QA/low could be more appropriate