Project

Summary

The burnBatchMultiple function, designed to batch-burn tokens across multiple accounts and token IDs, has a potential Denial of Service vulnerability. Specifically, it could be exploited to consume excessive gas by passing in a large number of addresses in the froms array, leading to transaction failures or a halt in function execution due to gas limit constraints.

Vulnerability Details

The burnBatchMultiple function has two nested loops:

• An outer loop iterating through each address in the froms array.

• An inner loop iterating through token IDs from 0 to 6.

• For each address-token ID pair, it checks the balance and then calls burn_ to burn tokens if a balance exists.

Because of this nested loop structure, gas usage increases with the size of froms. If a large array is passed, the function may hit the block gas limit, leading to transaction failure.

Each iteration costs:

• balanceOf: ~1,000 gas (storage read)

• burn_: ~5,000+ gas (storage write)

• Loop overhead: ~100 gas

• Total per address: Up to 7 * (6,100) = 42,700 gas

• Attack example: Array of 1000 addresses would consume: 42,700 * 1000 = 42.7M gas

Impact

The burnBatchMultiple function’s vulnerability can lead to a Denial of Service (DoS) by consuming excessive gas if a large array of addresses is passed, potentially causing transaction failures. This could disrupt legitimate uses of the function, making it unavailable and costly for intended users, while also risking state inconsistencies if only partial burns are completed.

Tools Used

• Manual Code Review

• Gas Analysis Tools - Remix

Recommendations

To mitigate the risk of DoS from excessive gas consumption in the burnBatchMultiple function, I recommend the following:
- Limit Array Length: Set a maximum allowed length for the froms array, ensuring that the function cannot be called with an excessive number of addresses. This could involve adding a require statement, such as: