CWE-909, Missing Initialization of Resource, applies when a product does not initialize a critical resource. It is a class level weakness, so it covers memory, variables, structures and other resources across languages.
How it happens
MITRE explains that many resources need initialization before use. If they do not get it, they may contain unpredictable or expired data, or defaults that are invalid for what the code expects. That matters for security when the resource is supposed to have certain properties or values.
The most common cause is a conditional. A variable is set in one branch and used on all paths.
int level;
if (user_is_admin(u)) {
level = ADMIN;
}
/* if the user is not admin, level was never set */
check_access(level);
The observed CVE-2020-20739 (details) follows this pattern: a variable has its value set in a conditional statement and is sometimes used when the conditional fails, sometimes causing data leakage.
A second example from MITRE, CVE-2005-1036, is a chain where an improperly initialized I/O permission bitmap led to improper authorization, so a missing initialization turned into an access control bypass.
What an attacker gains
MITRE lists two consequences:
- Confidentiality: when a resource is reused, its original contents may not be cleared before it is sent to an untrusted party.
- Availability: the uninitialized resource may hold values that change program flow in ways the author did not intend, which can crash or restart the program.
How to find it
MITRE says automated static analysis, or SAST, can find some instances by modeling data flow and control flow, and rates its effectiveness as high. In review, read every variable declaration and ask whether each path to its first use sets it.
How to fix it
From the MITRE mitigations:
- Explicitly initialize the resource before use. If an API or standard procedure does it, follow every required step.
- Pay close attention to complex conditionals that affect initialization, since some branches might not perform it.
- Avoid race conditions during initialization routines (see CWE-362).
- Build with settings that generate warnings about uninitialized variables, and treat those warnings as errors.
The safe version of the earlier snippet gives the variable a default at the declaration:
int level = NONE;
if (user_is_admin(u)) {
level = ADMIN;
}
check_access(level);
Quick check
Why does a conditional make this weakness likely?
Because one branch may set the value and the other may not, yet the code after the condition uses it either way.
What cheap control catches many cases?
Compiler warnings for uninitialized variables, enabled in the build and not ignored.
