The product does not implement or incorrectly implements wear leveling operations in limited-write non-volatile memories.

Non-volatile memories such as NAND Flash, EEPROM, etc. have individually erasable segments, each of which can be put through a limited number of program/erase or write cycles. For example, the device can only endure a limited number of writes, after which the device becomes unreliable. In order to wear out the cells in a uniform manner, non-volatile memory and storage products based on the above-mentioned technologies implement a technique called wear leveling. Once a set threshold is reached, wear leveling maps writes of a logical block to a different physical block. This prevents a single physical block from prematurely failing due to a high concentration of writes.

Primary

Architecture and Design

Implementation

Availability
DoS: Instability
If wear leveling is improperly implemented, attackers may be able to programmatically cause the storage to become unreliable within a much shorter time than would normally be expected.

Architecture and Design
Implementation
Testing

Include secure wear leveling algorithms and ensure they may not be bypassed.

High

An attacker can render a memory line unusable by repeatedly causing a write to the memory line.
Below is example code from [REF-1058] that the user can execute repeatedly to cause line failure. W is the maximum associativity of any cache in the system; S is the size of the largest cache in the system.

// Do aligned alloc of (W+1) arrays each of size S
while(1) {

for (ii = 0; ii < W + 1; ii++)

array[ii].element[0]++;

}

Without wear leveling, the above attack will be successful. Simple randomization of blocks will not suffice as instead of the original physical block, the randomized physical block will be worn out.

Wear leveling must be used to even out writes to the device.

Part 4-1
Req SD-4

Part 4-1
Req SI-1

Part 4-1
Req SVV-3

Allowed
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V Mangipudi
Intel Corporation
2020-02-10
4.0
2020-02-24

CWE Content Team
MITRE
2020-08-20
updated Demonstrative_Examples, Description, Potential_Mitigations, Research_Gaps

CWE Content Team
MITRE
2021-07-20
updated Related_Attack_Patterns

CWE Content Team
MITRE
2022-04-28
updated Applicable_Platforms

CWE Content Team
MITRE
2022-06-28
updated Applicable_Platforms

CWE Content Team
MITRE
2022-10-13
updated Demonstrative_Examples, Relationships, Research_Gaps

CWE Content Team
MITRE
2023-04-27
updated References, Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-04-03
4.17
2025-04-03
updated Demonstrative_Examples, References

CWE Content Team
MITRE
2025-09-09
4.18
2025-09-09
updated References

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Common_Consequences, Description, Weakness_Ordinalities

"Mapping CWE to 62443" Sub-Working Group
CWE-CAPEC ICS/OT SIG
2023-04-25
Suggested mappings to ISA/IEC 62443.

James Lang
LDRA
2024-04-23
Suggested fix for broken 404 reference URL.