Remove Redundant Assembly Masking in SafeTransferLib + Prevent Zero-Asset Mint in ERC4626

[timeless-hayoka]

Remove Redundant Assembly Masking in SafeTransferLib + Prevent Zero-Asset Mint in ERC4626

Removes redundant assembly masking based on Solidity ≥0.8.0 behavior, and fixes a zero-asset mint edge case in ERC4626 with test-backed validation.

1. Gas Optimization: Redundant Masking in SafeTransferLib

Problem

In SafeTransferLib.sol, the inline assembly blocks manually mask the from and to address arguments using and(address, 0xff...ff). This was a common defensive programming practice in Solidity <0.8.0 to ensure dirty upper bits were cleared before execution.

Root Cause & Justification

Under Solidity >=0.8.0, address-typed variables passed from Solidity into inline assembly are already sanitized by the compiler, making additional masking redundant in this context. There is no external raw calldata bypass that can sneak dirty bits into these specific local variables before the Yul block executes.

Solution

Removed the redundant and(..., 0xff...) masks from the inline assembly.

Impact

• Gas Reduced: 6 gas per safeTransfer/safeApprove call, and 10 gas per safeTransferFrom call. In DeFi protocols performing millions of transfers, this aggregate savings is significant.
• Verified via forge test --gas-report:
  • Before: testTransferWithStandardERC20() (gas: 64633)
  • After: testTransferWithStandardERC20() (gas: 64627)

No functional behavior changes; all existing tests pass unchanged.

2. Security Edge Case: Infinite Free Minting on Empty ERC4626 Vault

Problem

The ERC4626.sol implementation does not validate that assets != 0 during the mint sequence. While this is mathematically expected behavior because previewMint rounds up, it introduces a critical vulnerability when a vault has totalSupply > 0 but suffers a 100% loss (totalAssets() == 0). This condition can occur after slashing events, oracle failures, or external asset loss.

Root Cause

When totalAssets() == 0 but totalSupply > 0, previewMint(shares) calls mulDivUp(totalAssets(), totalSupply).
This evaluates to (shares * 0) / totalSupply which is exactly 0.
The mint function proceeds to transfer 0 assets from the caller, but still mints the requested shares.
An attacker can monitor a fully drained vault and mint an arbitrary amount of shares for zero assets, instantly diluting the pool so that if any assets are later recovered or donated back, the attacker can capture any subsequently deposited or recovered assets.

Solution

Added a strict non-zero check in mint, symmetrical to deposit:
require(assets != 0, "ZERO_ASSETS");

This mirrors the invariant already enforced in deposit (shares != 0), ensuring consistent behavior across entry points.

Impact & Proof

Protects ERC4626 integrations from being permanently bricked or stolen from during recovery scenarios following a slashing event.

Test Validation (testRevertMintZeroAssetsWhenVaultDrained):
Test fails on current main branch and passes with this fix.

• Before Fix: The exploit executes successfully; the attacker mints shares for 0 assets.
• After Fix: The exploit reverts precisely with "ZERO_ASSETS".