The product performs a power save/restore
operation, but it does not ensure that the integrity of
the configuration state is maintained and/or verified between
the beginning and ending of the operation.

Before powering down, the Intellectual
Property (IP) saves current state (S) to persistent
storage such as flash or always-on memory in order to
optimize the restore operation. During this process,
an attacker with access to the persistent storage may
alter (S) to a configuration that could potentially
modify privileges, disable protections, and/or cause
damage to the hardware. If the IP does not validate
the configuration state stored in persistent memory,
upon regaining power or becoming operational again,
the IP could be compromised through the activation of
an unwanted/harmful configuration.

Primary

Resultant

Architecture and Design
Weakness introduced via missing internal integrity guarantees during power save/restore

Integration
Weakness introduced via missing external integrity verification during power save/restore

Confidentiality
Integrity
DoS: Instability
DoS: Crash, Exit, or Restart
DoS: Resource Consumption (Other)
Gain Privileges or Assume Identity
Bypass Protection Mechanism
Alter Execution Logic
Quality Degradation
Unexpected State
Reduce Maintainability
Reduce Performance
Reduce Reliability
High

Architecture and Design
Inside the IP, incorporate integrity checking
on the configuration state via a cryptographic
hash. The hash can be protected inside the IP such as
by storing it in internal registers which never lose
power. Before powering down, the IP performs a hash of
the configuration and saves it in these persistent
registers. Upon restore, the IP performs a hash of the
saved configuration and compares it with the
saved hash. If they do not match, then the IP should
not trust the configuration.

Integration
Outside the IP, incorporate integrity checking
of the configuration state via a trusted agent. Before
powering down, the trusted agent performs a hash of the
configuration and saves the hash in persistent storage.
Upon restore, the IP requests the trusted agent
validate its current configuration. If the
configuration hash is invalid, then the IP should not
trust the configuration.

Integration
Outside the IP, incorporate a protected
environment that prevents undetected modification of
the configuration state by untrusted agents. Before
powering down, a trusted agent saves the IP's
configuration state in this protected location that
only it is privileged to. Upon restore, the trusted
agent loads the saved state into the IP.

The following pseudo code demonstrates the
power save/restore workflow which may lead to weakness
through a lack of validation of the config state after
restore.

void save_config_state()
{

void* cfg;

cfg = get_config_state();
save_config_state(cfg);

go_to_sleep();

}

void restore_config_state()
{

void* cfg;
cfg = get_config_file();
load_config_file(cfg);

}

The following pseudo-code is the proper workflow for the integrity checking mitigation:

void save_config_state()
{

void* cfg;
void* sha;

cfg = get_config_state();
save_config_state(cfg);

// save hash(cfg) to trusted location
sha = get_hash_of_config_state(cfg);
save_hash(sha);

go_to_sleep();

}

void restore_config_state()
{

void* cfg;
void* sha_1, sha_2;

cfg = get_config_file();
// restore hash of config from trusted memory
sha_1 = get_persisted_sha_value();

sha_2 = get_hash_of_config_state(cfg);
if (sha_1 != sha_2)

assert_error_and_halt();

load_config_file(cfg);

}

It must be noted that in the previous example of
good pseudo code, the memory (where the hash of the
config state is stored) must be trustworthy while the
hardware is between the power save and restore states.

Power

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.

Accellera Systems Initiative
2020-07-16
4.2
2020-08-20

CWE Content Team
MITRE
2021-03-15
updated Functional_Areas

CWE Content Team
MITRE
2021-07-20
updated Related_Attack_Patterns

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Weakness_Ordinalities