Description

The tokenInfos mapping is defined as a storage variable in Liquifier:

mapping(address => TokenInfo) public tokenInfos;

This mapping is keyed by ERC-20--token contract addresses and stores information about the particular token; TokenInfo is defined in ILiquifier:

struct TokenInfo {
    IStrategy strategy;
    uint128 strategyShare;
    uint128 ethAmountPendingForWithdrawals;
    bool isWhitelisted;
}

So, this storage mapping stores the strategy contract address corresponding to the token.

However, EigenLayer does not guarantee that one ERC-20 token will only have one whitelisted strategy. In fact, in a pre-M1 version of EigenLayer, the design allowed for the unpermissioned deployment and use of strategies, but a whitelist was added due to issues relating to reentrancy caused by malicious strategies.

Once EigenLayer whitelists more than one strategy for a particular ERC-20 token, this accounting breaks. The TokenInfo corresponding to the ERC-20 token cannot mention both strategies, and the accounted strategyShare will contain the sum of the shares for the strategies. These shares may be worth different amounts, so when the view function getTotalPooledEtherSplits is called and it calculates the restaked ETH value,

uint256 restaked = tokenAmountToEthAmount(_token, info.strategy.sharesToUnderlyingView(info.strategyShare));

this assumes that the strategy in the TokenInfo was the strategy that produced all the shares in strategyShare, which means it will return an incorrect value.

Impact

Currently, there is no impact. At the time of this audit, EigenLayer has only whitelisted nine strategies, all of which correspond to different ERC-20 tokens.

In the future, if EigenLayer ever whitelists two strategies that use the same underlying ERC-20, the view functions that estimate how much is pending liquification in the Liquifier will be incorrect.

Recommendations

Change the storage layout so that this mapping is keyed by strategy address instead of token address.

When remediating this issue, also consider Finding ref.

Remediation

This issue has been acknowledged by Gadze Finance SEZC, and a fix was implemented in commit dcd42be8↗. This finding was remediated by checking the strategy address of the withdrawal request against the one assigned to the token returned by an external call to the strategy. The design choice was made that one whitelisted token will only be covered by one strategy, set at the time the token is whitelisted.