ERC20Internals._mint and ERC20Internals._burn perform additions and subtractions on _totalSupply and account balances directly in Yul using add/sub without any overflow/underflow checks. In assembly, these operations are always wrapping modulo 2^256.

Description

• Normal behavior

  In a robust ERC20 implementation, minting and burning adjust the total supply and balances without allowing arithmetic to overflow or underflow:

  • Mint:

    • totalSupply increases by value if and only if totalSupply + value does not overflow.

    • balance[account] increases by value with similar checks.

  • Burn:

    • totalSupply decreases by value only when totalSupply >= value.

    • balance[account] decreases by value only when balance[account] >= value.

  If these conditions are not met, the operation naturally reverts to keep the token state consistent.

• Issue

  In this implementation, both _mint and _burn use raw Yul arithmetic:

  • add(supply, value) and add(accountBalance, value) in _mint.

  • sub(supply, value) and sub(accountBalance, value) in _burn

  These are unchecked and will wrap modulo 2^256 on overflow or underflow. There are no guards that ensure supply + value stays within range or that supply >= value / accountBalance >= value. As a result:

  
  

  • A large mint can cause _totalSupply and balances to wrap, potentially resetting to low values or rolling over.

  • A burn with value greater than supply or accountBalance will underflow and set them to huge values (close to type(uint256).max), effectively minting massive amounts of tokens instead of burning.

  
  

Risk

Likelihood:

• Whenever a derived contract or caller uses mint(account, value) with very large value (e.g. near type(uint256).max), the total supply and balances wrap around rather than reverting, corrupting the token’s state.

• Whenever burn(account, value) is called with value greater than the current balance or total supply, the subtraction wraps, causing the burned account and the total supply to become huge instead of reverting.

Impact:

• Token accounting invariants are broken: _totalSupply no longer meaningfully reflects the sum of balances, and both can jump to extremely large or small values unexpectedly.

• Attackers can exploit a misconfigured or permissionless burn/mint in derived contracts to create enormous balances or weird supply values, then use these manipulated balances to drain DeFi protocols integrating this token or to disrupt governance and accounting systems.

Proof of Concept

The following tests demonstrate:

1. Mint overflow: totalSupply and balance wrap when minting above type(uint256).max.

2. Burn underflow: burning more than the current balance underflows both totalSupply and the account balance to huge values.

You can paste these tests into Token.t.sol.

Recommended Mitigation

Use checked arithmetic semantics for _totalSupply and balances, either by:

• Moving these operations out of assembly into Solidity (benefiting from 0.8.x checked arithmetic), or

• Explicitly guarding for wraparound in Yul before sstore.

Conceptual diff (staying in assembly but adding explicit checks):