Liquid Staking

Summary

The OperatorVCS contract introduces a storage layout issue that could result in unexpected behavior and security risks. The contract replaces bool private preRelease; with address[] private vaultsToRemove;. Failure to maintain proper storage layout when upgrading contracts can lead to serious vulnerabilities.

Vulnerability Details

In Solidity, storage variables are stored sequentially in fixed 32-byte slots. A bool occupies a small portion of a slot, while a dynamic array like address[] requires multiple slots: one for the array's length and additional slots for each array element, starting at a location computed by keccak256(slot) where the slot is the position of the array length.

When upgrading from a bool to an address[], the new array will overwrite the storage slot previously used for the preRelease variable. This overwriting means that the array length will be stored in the same slot that once held the bool, resulting in invalid storage data for both the array and any nearby variables.

Impact

The corrupted storage layout can affect multiple functions that rely on the vaultsToRemove array, such as:

• getVaultRemovalQueue()

• removeVaults(...)

• queueVaultRemoval(...)

• getMaxDeposits()

These functions may encounter invalid or unexpected data, leading to incorrect contract behavior, loss of funds, or other unintended consequences. Additionally, overwritten or misplaced data in storage can lead to vulnerabilities that attackers could exploit.

Tools Used

• Manual review

Recommendations

• Keep the variable even if unused

• Use a new storage slot for the new variable.