Linea - Yield Manager

Description

During liquidity shortfalls, the system allows users to mint LST tokens against the staked ETH to satisfy bridge requests via claimMessageWithProofAndWithdrawLST(). To do so, users claiming bridge messages via LST withdrawal must specify a particular yield provider, but if that provider lacks sufficient userFunds to mint the required LST amount, the transaction reverts with LSTWithdrawalExceedsYieldProviderFunds:

contracts/contracts/yield/YieldManager.sol:L839-L857

function withdrawLST(
  address _yieldProvider,
  uint256 _amount,
  address _recipient
)
  external
  whenTypeAndGeneralNotPaused(PauseType.NATIVE_YIELD_PERMISSIONLESS_ACTIONS)
  onlyKnownYieldProvider(_yieldProvider)
{
  if (msg.sender != L1_MESSAGE_SERVICE) {
    revert SenderNotL1MessageService();
  }
  if (!ILineaRollupYieldExtension(L1_MESSAGE_SERVICE).isWithdrawLSTAllowed()) {
    revert LSTWithdrawalNotAllowed();
  }
  YieldProviderStorage storage $$ = _getYieldProviderStorage(_yieldProvider);
  if (_amount > $$.userFunds) {
    revert LSTWithdrawalExceedsYieldProviderFunds();
  }

However, since the message was already sent with a specified amount on the L2 Message Service, it is no longer possible for the user to change the amount:

contracts/contracts/messageService/l2/v1/L2MessageServiceV1.sol:L66

function sendMessage(address _to, uint256 _fee, bytes calldata _calldata) external payable {

contracts/contracts/messageService/l2/v1/L2MessageServiceV1.sol:L94

bytes32 messageHash = MessageHashing._hashMessage(msg.sender, _to, postmanFee, valueSent, messageNumber, _calldata);

As a result, if there is no single yield provider that can satisfy the full request, it will never be possible for this message to be claimed via the claimMessageWithProofAndWithdrawLST() route. The user will be forced to wait until sufficient liquidity is restored on the L1 Message Service.

Recommendation

Consider implementing a mechanism to choose multiple yield providers to satisfy LST withdrawals.

Description

The ValidatorContainerProofVerifier validates beacon chain proofs against EIP-4788 beacon roots that does not enforce proof recency beyond the 8191-block (~27 hour) history window. This allows attackers to submit valid but stale proofs that reflect a validator’s historical high balance, while the validator’s current balance is significantly lower (due to slashing, partial withdrawals, or balance reductions). This creates unfulfillable withdrawal requests that permanently inflate pendingPermissionlessUnstake, causing a denial-of-service on legitimate permissionless unstake operations.

The attack exploits the timing window when validators experience balance reductions. An attacker can:

1. Identify a validator that experienced a balance reduction (e.g., from 2000 ETH to 100 ETH)
2. Generate a proof from before the reduction (up to 27 hours old, when balance was 2000 ETH)
3. Submit unstakePermissionless with amounts[0] set to the historical high balance (2000 ETH)
4. The proof verification passes (stale but valid), computing maxUnstakeAmountGwei = Math256.min(2000e9, effectiveBalance - 32e9) ≈ 1968 ETH
5. The system increments pendingPermissionlessUnstake by 1968 ETH
6. The withdrawal request is submitted to beacon chain for 1968 ETH
7. However, the validator only has 100 ETH, so 1868 ETH of the withdrawal is unfulfillable

This creates an accounting discrepancy where pendingPermissionlessUnstake, a value stored in the YieldManager contract that is used to track unstaking requests, is permanently inflated by the unfulfillable amount. In turn, the YieldManager contract uses this variable to limit unstaking requests by users so they don’t unstake more than required by the deficit:

contracts/contracts/yield/YieldManager.sol:L570-L576

uint256 targetDeficit = getTargetReserveDeficit();
uint256 availableFundsToSettleTargetDeficit = address(this).balance +
  withdrawableValue(_yieldProvider) +
  _getYieldManagerStorage().pendingPermissionlessUnstake;
if (availableFundsToSettleTargetDeficit + maxUnstakeAmount > targetDeficit) {
  revert PermissionlessUnstakeRequestPlusAvailableFundsExceedsTargetDeficit();
}

However, in our case the stored pendingPermissionlessUnstake will never decrease from the unfulfillable requests, as it only gets reduced during succesful withdrawals:

contracts/contracts/yield/YieldManager.sol:L619-L629

function _delegatecallWithdrawFromYieldProvider(address _yieldProvider, uint256 _amount) internal {
  YieldProviderStorage storage $$ = _getYieldProviderStorage(_yieldProvider);
  _delegatecallYieldProvider(
    _yieldProvider,
    abi.encodeCall(IYieldProvider.withdrawFromYieldProvider, (_yieldProvider, _amount))
  );
  $$.userFunds -= _amount;
  _getYieldManagerStorage().userFundsInYieldProvidersTotal -= _amount;
  // Greedily reduce pendingPermissionlessUnstake with every withdrawal made from the yield provider.
  _decrementPendingPermissionlessUnstake(_amount);
}

As a result, if users perform enough of such unfulfillable requests up the maximum possible amount, the availableFundsToSettleTargetDeficit + maxUnstakeAmount > targetDeficit check will revert for future legitimate unstake requests, causing a DoS in the permissionless unstaking feature. This can be alleviated with other withdrawals such as those by permissioned unstaking requests, but permissionless unstaking requests would be blocked until that time.

Moreover, this attack can be done by using the same proof, repeating it to hit the limit of the maximum pendingPermissionlessUnstake as needed.

Recommendation

As in issue 5.3 , though the cause of the issue is the lack of instant synchronization between the beacon chain and the execution layer, requiring the proofs to be more recent would not solve the issue. A proof as old as 1 slot ago would still be stale, showing incorrect information. Instead, tracking needs to be implemented that ensures that any permissionless unstaking blocks any other requests that contain proofs that haven’t had the chance to update for the pending withdrawal information.

Description

The ValidatorContainerProofVerifier validates beacon chain proofs against EIP-4788 beacon roots but does not enforce proof recency beyond the 8191-block (~27 hour) history window guaranteed by the beacon roots contract. This allows attackers to submit valid but stale proofs that reflect a validator’s historical low balance, while requesting unstaking of a much larger current balance. The vulnerability leads to incorrect accounting in pendingPermissionlessUnstake, as the system tracks only the historical difference between effective balance and activation balance (potentially very small), while the actual unstaking request withdraws the full requested amount.

The attack exploits the timing window when validators are topped up with additional ETH. An attacker can:

• Identify a validator with low balance (e.g., newly activated at 32 ETH)
• Wait for the validator to be topped up with additional funds
• Generate a proof from before the top-up (up to 27 hours old)
• Submit unstakePermissionless with amounts[0] set to the entire top-up amount
• The proof verification passes (stale but valid), computing maxUnstakeAmountGwei = Math256.min(amounts[0], effectiveBalance - 32e9) ≈ 0
• The system increments pendingPermissionlessUnstake by only the small maxUnstakeAmount (near zero)
• However, the actual withdrawal request proceeds with the full amounts[0], withdrawing significantly more ETH than tracked
• This creates an accounting discrepancy where availableFundsToSettleTargetDeficit + maxUnstakeAmount > targetDeficit checks can be bypassed, allowing excessive unstaking beyond intended limits.

Repeated exploitation can:

• Bypass the permissionless unstake caps designed to prevent over-unstaking
• Create a permanent DoS on validator top-ups (any top-up gets immediately exploited and unstaked)

Examples

The unstakePermissionless() request validates against stale witness data but ultimately submits the user-provided amounts to _unstake(), which is not changed by _validateUnstakePermissionlessRequest() as opposed to maxUnstakeAmount:

contracts/contracts/yield/LidoStVaultYieldProvider.sol:L311-L321

function unstakePermissionless(
  address _yieldProvider,
  bytes calldata _withdrawalParams,
  bytes calldata _withdrawalParamsProof
) external payable onlyDelegateCall returns (uint256 maxUnstakeAmount) {
  (bytes memory pubkeys, uint64[] memory amounts, address refundRecipient) = abi.decode(
    _withdrawalParams,
    (bytes, uint64[], address)
  );
  maxUnstakeAmount = _validateUnstakePermissionlessRequest(_yieldProvider, pubkeys, amounts, _withdrawalParamsProof);
  _unstake(_yieldProvider, pubkeys, amounts, refundRecipient);

contracts/contracts/yield/LidoStVaultYieldProvider.sol:L372-L381

  VALIDATOR_CONTAINER_PROOF_VERIFIER.verifyActiveValidatorContainer(witness, _pubkeys, withdrawalCredentials);

  // https://github.com/ethereum/consensus-specs/blob/master/specs/electra/beacon-chain.md#modified-get_expected_withdrawals
  uint256 maxUnstakeAmountGwei = Math256.min(
    amount,
    Math256.safeSub(witness.effectiveBalance, MIN_0X02_VALIDATOR_ACTIVATION_BALANCE_GWEI)
  );
  // Convert from Beacon Chain units of 'gwei' to execution layer units of 'wei'
  maxUnstakeAmount = maxUnstakeAmountGwei * 1 gwei;
}

The returned maxUnstakeAmount is then validated and registered into the state on the YieldManager contract:

contracts/contracts/yield/YieldManager.sol:L561-L576

bytes memory data = _delegatecallYieldProvider(
  _yieldProvider,
  abi.encodeCall(IYieldProvider.unstakePermissionless, (_yieldProvider, _withdrawalParams, _withdrawalParamsProof))
);
maxUnstakeAmount = abi.decode(data, (uint256));
if (maxUnstakeAmount == 0) {
  revert YieldProviderReturnedZeroUnstakeAmount();
}
// Validiate maxUnstakeAmount
uint256 targetDeficit = getTargetReserveDeficit();
uint256 availableFundsToSettleTargetDeficit = address(this).balance +
  withdrawableValue(_yieldProvider) +
  _getYieldManagerStorage().pendingPermissionlessUnstake;
if (availableFundsToSettleTargetDeficit + maxUnstakeAmount > targetDeficit) {
  revert PermissionlessUnstakeRequestPlusAvailableFundsExceedsTargetDeficit();
}

It is important to note that the full 8192 slot period is not the root cause, and even a 1 slot long period could allow for this issue. As long as the information between the beacon chain and the execution layer is not synced instantly, a user could submit a proof that is not current.

Recommendation

Enforce that the validated maxUnstakeAmount that is the result of the witness proof calculation is used for the subsequent _unstake() request on the beacon chain to synchronize the requested withdrawal amount and the recorded amount in the YieldManager state.

Description

The YieldManager contract tracks and limits how much unstaking can be requested permissionlessly via the storage variable pendingPermissionlessUnstake. It is incremented upon each succesfull request via unstakePermissionless(), and it is also checked on each subsequent call to protect against over-unstaking:

contracts/contracts/yield/YieldManager.sol:L570-L578

uint256 targetDeficit = getTargetReserveDeficit();
uint256 availableFundsToSettleTargetDeficit = address(this).balance +
  withdrawableValue(_yieldProvider) +
  _getYieldManagerStorage().pendingPermissionlessUnstake;
if (availableFundsToSettleTargetDeficit + maxUnstakeAmount > targetDeficit) {
  revert PermissionlessUnstakeRequestPlusAvailableFundsExceedsTargetDeficit();
}

_getYieldManagerStorage().pendingPermissionlessUnstake += maxUnstakeAmount;

To allow for future unstaking requests, it is decremented during _delegatecallWithdrawFromYieldProvider() when ETH is pulled from a yield provider to the YieldManager contract:

contracts/contracts/yield/YieldManager.sol:L619-L636

function _delegatecallWithdrawFromYieldProvider(address _yieldProvider, uint256 _amount) internal {
  YieldProviderStorage storage $$ = _getYieldProviderStorage(_yieldProvider);
  _delegatecallYieldProvider(
    _yieldProvider,
    abi.encodeCall(IYieldProvider.withdrawFromYieldProvider, (_yieldProvider, _amount))
  );
  $$.userFunds -= _amount;
  _getYieldManagerStorage().userFundsInYieldProvidersTotal -= _amount;
  // Greedily reduce pendingPermissionlessUnstake with every withdrawal made from the yield provider.
  _decrementPendingPermissionlessUnstake(_amount);
}

function _decrementPendingPermissionlessUnstake(uint256 _amount) internal {
  YieldManagerStorage storage $ = _getYieldManagerStorage();
  uint256 pendingPermissionlessUnstakeAmount = $.pendingPermissionlessUnstake;
  if (pendingPermissionlessUnstakeAmount == 0) return;
  $.pendingPermissionlessUnstake = Math256.safeSub(pendingPermissionlessUnstakeAmount, _amount);
}

However, this function is called on every withdrawal from the yield provider, not just those withdrawals that are associated with permissionless unstaking requests. As a result, this allows additional permissionless unstakes beyond the intended limits, potentially causing excessive unstaking when reserves are already being restored through regular unstake operations.

For example, when a regular unstake() for X ETH is initiated first, followed by unstakePermissionless() calls up to the target limit, the completion of the regular unstake() via withdrawFromYieldProvider() decrements pendingPermissionlessUnstake by X ETH. This reduction would allow for another X ETH worth of additional permissionless unstaking capacity, bypassing the check associated with the PermissionlessUnstakeRequestPlusAvailableFundsExceedsTargetDeficit error that should prevent over-unstaking.

This instance of over-unstaking may happen when there is a pending unstake() and the system is in target deficit which would also allow to initiate unstakePermissionless() at the same time.

Recommendation

Consider accounting for permissioned unstaking requests when calculating the maximum amounts of permissionless unstaking requests. Consider implementing a tie-in mechanism between each unstaking request and the withdrawals that follow.

Description

A large ETH depositor can orchestrate a reserve depletion attack by inflating system reserves with a massive deposit, waiting for automated staking to occur, then immediately withdrawing the full amount. As the balance has already been sent for staking operations, this forces the protocol to satisfy withdrawals using LST tokens via claimMessageWithProofAndWithdrawLST():

contracts/contracts/LineaRollupYieldExtension.sol:L138-L153

function claimMessageWithProofAndWithdrawLST(
  ClaimMessageWithProofParams calldata _params,
  address _yieldProvider
) external virtual nonReentrant {
  if (_params.value < address(this).balance) {
    revert LSTWithdrawalRequiresDeficit();
  }
  if (msg.sender != _params.to) {
    revert CallerNotLSTWithdrawalRecipient();
  }
  bytes32 messageLeafHash = _validateAndConsumeMessageProof(_params);
  IS_WITHDRAW_LST_ALLOWED = true;
  IYieldManager(yieldManager()).withdrawLST(_yieldProvider, _params.value, _params.to);
  IS_WITHDRAW_LST_ALLOWED = false;
  emit MessageClaimed(messageLeafHash);
}

This creates substantial LST liabilities that require a sum of 1) staking queue period for the staking funds to arrive to the beacon chain and 2) partial withdrawal queue to return the funds from the beacon chain to the Message Service. During this period, LST liabilities continue growing while rewards do not get generating in the staking queue. Essentially, this attack would incur fees and liabilities on Linea staking operations but wouldn’t yield anything for the attacker.

Example attack for a system with 100,000 ETH total and a 50% reserve target.

1. Large holder deposits 200,000 ETH increasing L1MessageService balance from 50,000 to 250,000 ETH
2. Automation service stakes 100,000 ETH based on 50% target reserve, leaving 150,000 ETH in reserves
3. The large holder withdraws 200,000 ETH, depleting L1MessageService balance to zero and forcing 50,000 ETH to be fulfilled via LST withdrawals.

Recommendation

Implement defensive reserve percentage calculations based on maximum tolerable attacker balance rather than arbitrary values. Modify rebalancing logic to account for both reserve deficits and outstanding LST liabilities when determining withdrawal amounts from validators. Consider implementing rate limits on both L1MessageService-to-staking transfers and LST withdrawals to increase attack cost and cap liability growth during bank-run scenarios.

Description

The LST withdrawal function claimMessageWithProofAndWithdrawLST() enforces that only the original to address specified in the withdrawal request can claim the funds (requiring to == msg.sender):

contracts/contracts/LineaRollupYieldExtension.sol:L138-L147

function claimMessageWithProofAndWithdrawLST(
  ClaimMessageWithProofParams calldata _params,
  address _yieldProvider
) external virtual nonReentrant {
  if (_params.value < address(this).balance) {
    revert LSTWithdrawalRequiresDeficit();
  }
  if (msg.sender != _params.to) {
    revert CallerNotLSTWithdrawalRecipient();
  }

This is in contrast to the regular ETH claiming function that allows the Message Service contract to actually perform a low level call to the recipient to address with an associated value value:

contracts/contracts/messageService/l1/L1MessageService.sol:L87-L94

function claimMessageWithProof(
  ClaimMessageWithProofParams calldata _params
) external nonReentrant distributeFees(_params.fee, _params.to, _params.data, _params.feeRecipient) {
  bytes32 messageLeafHash = _validateAndConsumeMessageProof(_params);

  TransientStorageHelpers.tstoreAddress(MESSAGE_SENDER_TRANSIENT_KEY, _params.from);

  (bool callSuccess, bytes memory returnData) = _params.to.call{ value: _params.value }(_params.data);

Considering the claimMessageWithProofAndWithdrawLST() is meant to be a substitute for calling claimMessageWithProof() in events of liquidity shortfall on the L1 Message Service due to staking operations, the users performing the message claim may not be anticipating the to==msg.sender requirement, as that is not the case with claimMessageWithProof()

This creates a risk where withdrawal requests to treasury, multisig or other smart contracts that cannot execute arbitrary function calls will become temporarily stuck, effectively locking user funds until funds are replenished on the L1 Message Service.

Recommendation

Consider relaxing the to==msg.sender requirement to allow claiming on behalf of the recipients.

Description

A large ETH holder can exploit the unstaking mechanism by timing large withdrawals to coincide with pending regular unstaking operations. The system calculates permissionless unstaking requirements based on current balance without accounting for incoming funds from pending regular unstaking, allowing attackers to force the protocol to over-unstake beyond intended limits. This occurs because the system doesn’t track or subtract pending incoming unstaking amounts when determining how much additional permissionless unstaking is needed to reach minimum thresholds.

The vulnerability manifests in the following attack sequence:

• System initiates regular unstaking (e.g., 5k ETH) to reach target balance via unstake()
• Attacker times large withdrawal (e.g., 10-30k ETH) while regular unstaking is pending
• System calculates permissionless unstaking requirement based on post-withdrawal balance, ignoring incoming regular unstaking:

contracts/contracts/yield/YieldManager.sol:L570-L576

uint256 targetDeficit = getTargetReserveDeficit();
uint256 availableFundsToSettleTargetDeficit = address(this).balance +
  withdrawableValue(_yieldProvider) +
  _getYieldManagerStorage().pendingPermissionlessUnstake;
if (availableFundsToSettleTargetDeficit + maxUnstakeAmount > targetDeficit) {
  revert PermissionlessUnstakeRequestPlusAvailableFundsExceedsTargetDeficit();
}

• When regular unstaking completes, pendingPermissionlessUnstake is decremented via safeSub but incoming funds push balance above minimum
• Result: System has over-unstaked by the amount of the original regular unstaking

Example scenario: With 100k ETH total funds (40% min reserve, 50% target reserve) and 50k ETH on the L1 Message Service, after a 10k ETH withdrawal and 5k ETH regular unstaking initiated, a subsequent 30k ETH withdrawal may trigger a 14k ETH permissionless unstaking. When the original 5k ETH regular unstaking completes, total unstaking becomes 19k ETH instead of the required 14k ETH, exceeding intended limits by 5k ETH.

Recommendation

Consider implementing tracking of pending regular unstaking amounts to tie all withdrawal operations with associated unstaking requests. Consequently, account for all unstaking requests amounts to prevent over-unstaking.

Description

The Yield Manager decrements pendingPermissionlessUnstake whenever funds are withdrawn from the Staking Vault to the L1 reserve, incorrectly assuming these withdrawals represent completed unstaking operations. However, withdrawal operations extract liquid funds already available in the Staking Vault, not funds arriving from beacon chain unstaking.

This creates an accounting mismatch: the system tracks fewer pending unstake funds than actually exist, allowing additional permissionless unstaking that exceeds intended thresholds. The actual unstaked funds remain pending on the beacon chain while the system permits new unstake operations.

Initial State:

Action: withdrawFromYieldProvider(100) extracts 100 ETH liquid funds from Staking Vault to L1 reserve

Resulting State:

Issue: The system now permits an additional 100 ETH of permissionless unstaking, but the original 200 ETH from permissionless unstaking is still pending on the beacon chain. The withdrawn 100 ETH was pre-existing liquid balance, not unstaking proceeds.

Impact: Permissionless unstaking exceeds intended thresholds by the amount of liquid funds withdrawn, resulting in reduced yield efficiency.

The greedy decrement approach is a design trade-off: the system cannot distinguish whether Staking Vault funds originate from unstaking completions, staking yield, or direct deposits. This approach prioritizes the core objective of maintaining user withdrawal liquidity over perfect yield efficiency.

Description

The system has inconsistent logic for determining when to pause staking across different withdrawal functions, leading to scenarios where staking is paused unnecessarily despite sufficient liquid funds being available.

Expected Behavior: replenishWithdrawalReserve correctly considers both Yield Manager balance and Yield Provider balance when determining if liquid funds can cover the target deficit, only pausing staking when these combined funds are insufficient.

Inconsistent Implementations:

1. withdrawFromYieldProvider Issue: This function ignores the Yield Manager balance entirely. It withdraws only the caller-specified amount from the Yield Provider and pauses staking if the amount sent to the L1_Message_service reserve is less than the target deficit.

Problematic scenarios:

• Scenario A: Substantial funds exist in the Yield Manager, but the Yield Provider balance alone is less than the target deficit. Staking is paused despite total liquid funds being sufficient.
• Scenario B: Caller passes an amount smaller than the Yield Provider’s available balance, even though the full Yield Provider balance could cover the deficit. Staking is paused unnecessarily.

2. _addToWithdrawalReserve Issue: This function pauses staking if the input amount is less than the target deficit. The behavior differs based on the caller:

• When called via safeAddToWithdrawalReserve: Safe because it considers full Yield Manager and Yield Provider balances
• When called via addToWithdrawalReserve: Vulnerable because it only considers the input amount, enabling a frontrunning attack where an attacker withdraws from L1 reserve to increase the deficit, causing the function to incorrectly pause staking despite sufficient liquid funds remaining

Impact: Staking may be paused prematurely in situations where combined liquid funds (Yield Manager + Yield Provider) are sufficient to cover the target deficit, reducing yield generation without justification.

Recommendation: All withdrawal functions should consistently evaluate total liquid funds (Yield Manager balance + Yield Provider balance) before determining whether to pause staking.

Description

Lido’s 20% external shares limit may prevent emergency LST withdrawals during liquidity crises, forcing users into slower beacon chain withdrawal queues when immediate liquidity is most needed.

Lido caps external shares at 20% of total stETH supply via _getMaxMintableExternalShares(). The Linea Yield Management system relies on LST minting as emergency liquidity when L1MessageService reserves are insufficient, executed through claimMessageWithProofAndWithdrawLST() → withdrawLST() → IDashboard.mintStETH().

Risk Scenario

As other L2s adopt similar yield strategies, external shares utilization could approach the 20% limit through:

• Capital migration from traditional stETH to L2 yield strategies
• Multiple L2s competing for the same external shares allocation
• Composition shifts even without net new demand

When the limit is reached, Lido rejects new stETH minting requests, denying users emergency liquidity access.

Impact

• Emergency liquidity denial during withdrawal crises
• Unpredictable LST availability undermining system reliability
• Forced beacon chain queues (days/weeks delay) during stressed conditions

This represents a systemic constraint outside the protocol’s direct control that could impact emergency liquidity provision.

Description

The _hashMessageWithEmptyCalldata function performs an unnecessary memory store operation at position 0xe0 before hashing. Since the keccak256 operation only hashes up to position 0xe0 (exclusive), storing data at that position serves no purpose and wastes gas.

contracts/contracts/messageService/lib/MessageHashing.sol:L58-L77

function _hashMessageWithEmptyCalldata(
  address _from,
  address _to,
  uint256 _fee,
  uint256 _valueSent,
  uint256 _messageNumber
) internal pure returns (bytes32 messageHash) {
  assembly {
    let mPtr := mload(0x40)
    mstore(mPtr, _from)
    mstore(add(mPtr, 0x20), _to)
    mstore(add(mPtr, 0x40), _fee)
    mstore(add(mPtr, 0x60), _valueSent)
    mstore(add(mPtr, 0x80), _messageNumber)
    mstore(add(mPtr, 0xa0), 0xc0)
    mstore(add(mPtr, 0xc0), 0x00)
    mstore(add(mPtr, 0xe0), 0x00)
    messageHash := keccak256(mPtr, 0xe0)
  }
}

Recommendation

Remove the unnecessary mstore(add(mPtr, 0xe0), 0x00) operation to optimize gas usage.

Description

When withdrawing from the bridge with LST tokens via claimMessageWithProofAndWithdrawLST(), we require the requested amount to not be strictly less than the balance of the message service to enable this route:

contracts/contracts/LineaRollupYieldExtension.sol:L138-L144

function claimMessageWithProofAndWithdrawLST(
  ClaimMessageWithProofParams calldata _params,
  address _yieldProvider
) external virtual nonReentrant {
  if (_params.value < address(this).balance) {
    revert LSTWithdrawalRequiresDeficit();
  }

The idea is that if there is enough to satisfy on the bridge, LST withdrawal shouldn’t happen, as per the comment “…withdraws LST from the specified yield provider when the L1MessageService balance is insufficient to fulfill delivery” However, if there is an equal amount, that is also sufficient, and in this case the LST withdrawal is still permissible. In other words, the check should be <= instead of <.

Recommendation

Adjust the inequality check to <=.

Description

YieldProviderBase does 0-address checks for _l1MessageService and _yieldManager in its constructor:

contracts/contracts/yield/YieldProviderBase.sol:L21-L23

constructor(address _l1MessageService, address _yieldManager) {
  ErrorUtils.revertIfZeroAddress(_l1MessageService);
  ErrorUtils.revertIfZeroAddress(_yieldManager);

However, the child contract LidoStVaultYieldProvider does the same checks as well, which is unnecessary:

contracts/contracts/yield/LidoStVaultYieldProvider.sol:L84-L93

constructor(
  address _l1MessageService,
  address _yieldManager,
  address _vaultHub,
  address _vaultFactory,
  address _steth,
  address _validatorContainerProofVerifier
) YieldProviderBase(_l1MessageService, _yieldManager) {
  ErrorUtils.revertIfZeroAddress(_l1MessageService);
  ErrorUtils.revertIfZeroAddress(_yieldManager);

Recommendation

Remove unnecessary 0-address checks in the LidoStVaultYieldProvider contract.

Description

LineaRollupYieldExtension does not check if _yieldManager is 0 in its __LineaRollupYieldExtension_init() function, as that is done in the LineaRollup initialize().

contracts/contracts/LineaRollupYieldExtension.sol:L51-L54

function __LineaRollupYieldExtension_init(address _yieldManager) internal onlyInitializing {
  emit YieldManagerChanged(_storage()._yieldManager, _yieldManager);
  _storage()._yieldManager = _yieldManager;
}

contracts/contracts/LineaRollup.sol:L23-L29

function initialize(InitializationData calldata _initializationData) external initializer {
  __LineaRollup_init(_initializationData);
  if (_initializationData.initialYieldManager == address(0)) {
    revert ZeroAddressNotAllowed();
  }
  __LineaRollupYieldExtension_init(_initializationData.initialYieldManager);
}

However, LineaRollupYieldExtension does perform the 0-address check on _yieldManager in the setter function for this variable:

contracts/contracts/LineaRollupYieldExtension.sol:L87-L92

function setYieldManager(address _newYieldManager) public onlyRole(SET_YIELD_MANAGER_ROLE) {
  require(_newYieldManager != address(0), ZeroAddressNotAllowed());
  LineaRollupYieldExtensionStorage storage $ = _storage();
  emit YieldManagerChanged($._yieldManager, _newYieldManager);
  $._yieldManager = _newYieldManager;
}

It would be more consistent to perform all 0-address checks for the _yieldManager variable within the LineaRollupYieldExtension contract.

Recommendation

Move the 0-address check for the _yieldManager variable from LineaRollup.initialize() to LineaRollupYieldExtension.__LineaRollupYieldExtension_init()

Description

The Linea rollup has recently introduced a feature into its message claiming flow where a claimed message could burn LINEA tokens from the L1LineaTokenBurner contract:

../contracts/src/operational/L1LineaTokenBurner.sol:L31-L36

/**
 * @notice Claims a message with proof and burns the LINEA tokens held by this contract.
 * @dev This is expected to be permissionless, allowing anyone to trigger the burn.
 * @param _params The parameters required to claim the message with proof.
 */
function claimMessageWithProof(IL1MessageService.ClaimMessageWithProofParams calldata _params) external {

In the feature set of the scope of the current audit, there is also a new functionality introduced into the message claiming flow - claimMessageWithProofAndWithdrawLST. In the event of a liquidity shortfall on the L1 Message Service contract due to staking operations, users may utilize this function to withdraw stETH instead of ETH, effectively offering an alternative to a normal claimMessageWithProof function.

As a result, for full feature parity it may be worth it to consider introducing a call (with associated necessary changes) to this function in the L1LineaTokenBurner contract as well, so that the LINEA tokens may be burnt through this flow as well.

Recommendation

Consider the claimMessageWithProofAndWithdrawLST function to enable LINEA burning via L1LineaTokenBurner.

Description

Protected functions in the YieldManager contract have inconsistent natspec documentation regarding required roles. Some functions properly document the required role in their @dev comments while others don’t.

Examples

• reportYield with @dev:

contracts/contracts/yield/YieldManager.sol:L470-L472

/**
 * @notice Report newly accrued yield for the YieldProvider since the last report.
 * @dev YIELD_REPORTER_ROLE is required to execute.

• initiateOssification without:

contracts/contracts/yield/YieldManager.sol:L870-L876

/**
 * @notice Initiate the ossification sequence for a provider.
 * @dev Will pause beacon chain staking and LST withdrawals.
 * @dev WARNING: This operation irreversibly pauses beacon chain deposits.
 * @param _yieldProvider The yield provider address.
 */
function initiateOssification(

Recommendation

Adjust @dev comments as needed.

Description

This is a self-reported issue found by the Linea team. When LST liabilities exist in the system, all withdrawal operations from the Yield Manager become blocked due to a stale withdrawable value calculation.

Intended Flow:

The Yield Manager’s withdrawal functions follow this pattern:

1. Query dashboard.withdrawableValue() to determine how much can be withdrawn
2. Pass that value to dashboard.withdraw() to execute the withdrawal

Actual Behavior:

The issue occurs when LST liabilities are present in the system. The withdrawal flow executes as follows:

1. Yield Manager calls dashboard.withdrawableValue() and stores the result (e.g., 1000 ETH)
2. Yield Manager calls dashboard.withdraw(1000)
3. This triggers LidoStVaultYieldProvider::withdrawFromYieldProvider
4. Before the actual withdrawal, _payMaximumPossibleLSTLiability() is called
5. This payment reduces the StakingVault’s available funds
6. The withdrawable value drops (e.g., from 1000 ETH to 800 ETH)
7. The system attempts to withdraw the original 1000 ETH
8. The Dashboard reverts with ExceedsWithdrawable because only 800 ETH is now available

Exploit Path:

1. Attacker calls withdrawLST with any non-zero amount to create LST liabilities
2. All subsequent withdrawal operations fail, blocking legitimate withdrawals from the L1 reserve

Root Cause:

The withdrawable value is calculated before the LST liability payment occurs. Since the liability payment reduces available funds, the calculated withdrawal amount becomes stale and exceeds what is actually withdrawable, causing the transaction to revert.

Impact:

Denial of service for all Yield Manager withdrawal operations when LST liabilities exist. This prevents the system from replenishing the L1 reserve, potentially blocking user withdrawals.

Description

This is a self-reported issue found by the Linea team during testing. When progressPendingOssification is called, there was no check to verify that stagedBalance was non-zero before calling the unstage function. If stagedBalance is zero, the unstage call would revert, blocking full ossification from completing.