_burn Function Lacks Overflow Check, Leading to Manipulation of Total Supply and Balance

Description

In the _burn function of an ERC20 token, it is crucial to ensure that the amount being burned does not exceed the current total supply and the account balance to prevent underflow.
However, the function directly uses Yul's sub instruction to perform subtraction without verifying supply >= value and accountBalance >= value.
Since sub(a, b) in Yul silently wraps around to a very large value (i.e., a negative number under modulo 2²⁵⁶) when a < b, this will cause _totalSupply or the user's balance to be incorrectly set to an invalid value close to type(uint256).max, severely disrupting the token's state consistency.

Risk

Likelihood:

• When value passed to _burn is greater than the account balance or total supply (e.g., due to logical errors, malicious calls, or external contract integration defects), underflow will be triggered.

• Since the function is internal, if the upper-level business logic (such as custom burn interfaces) lacks verification, this risk is easily exposed.

Impact:

• _totalSupply or user balance becomes an extremely large value due to underflow, destroying the token's total supply conservation and ledger correctness.

• May cause catastrophic errors in other logic dependent on balance or supply (such as dividends, staking, governance), or even lead to fund theft or freezing.

Proof of Concept

• Add the function test_1_burn_overflow in Token.t.sol as follows:

• Input command: forge test --mt test_1_burn_overflow -vv

Recommended Mitigation