Local, automatic variables assume unexpected values if they are read before they are initialized. The C++ Standard, [dcl.init], paragraph 12, states [ISO/IEC 14882-2014]:
If no initializer is specified for an object, the object is default-initialized. When storage for an object with automatic or dynamic storage duration is obtained, the object has an indeterminate value, and if no initialization is performed for the object, that object retains an indeterminate value until that value is replaced. If an indeterminate value is produced by an evaluation, the behavior is undefined except in the following cases:
— If an indeterminate value of unsigned narrow character type is produced by the evaluation of:
— the second or third operand of a conditional expression,
— the right operand of a comma expression,
— the operand of a cast or conversion to an unsigned narrow character type, or
— a discarded-value expression,
then the result of the operation is an indeterminate value.
— If an indeterminate value of unsigned narrow character type is produced by the evaluation of the right operand of a simple assignment operator whose first operand is an lvalue of unsigned narrow character type, an indeterminate value replaces the value of the object referred to by the left operand.
— If an indeterminate value of unsigned narrow character type is produced by the evaluation of the initialization expression when initializing an object of unsigned narrow character type, that object is initialized to an indeterminate value.
The default initialization of an object is described by paragraph 7 of the same subclause:
To default-initialize an object of type
T
means:
— ifT
is a (possibly cv-qualified) class type, the default constructor forT
is called (and the initialization is ill-formed ifT
has no default constructor or overload resolution results in an ambiguity or in a function that is deleted or inaccessible from the context of the initialization);
— ifT
is an array type, each element is default-initialized;
— otherwise, no initialization is performed.
If a program calls for the default initialization of an object of a const-qualified typeT
,T
shall be a class type with a user-provided default constructor.
As a result, objects of type T
with automatic or dynamic storage duration must be explicitly initialized prior to having their value read as part of an expression, except if T
is a class type or array thereof, or an unsigned narrow character type. If T
is an unsigned narrow character type, it may be used to initialize an object of unsigned narrow character type, which results in both objects having an indeterminate value. This can be used to implement copy operations like std::memcpy()
without triggering undefined behavior.
Additionally, memory dynamically allocated with a new
expression is default-initialized when the new-initialized is omitted. Memory allocated by the standard library function std::calloc()
is zero-initialized. Memory allocated by the standard library function std::realloc()
assumes the values of the original pointer, but may not initialize the full range of memory. Memory allocated by any other means (std::malloc()
, allocator objects, operator new()
, etc) is assumed to be default-initialized.
Objects of static or thread storage duration are zero-initialized before any other initialization takes place [ISO/IEC 14882-2014], and need not be explicitly initialized prior to having their value read.
Noncompliant Code Example
In this noncompliant code example, an uninitialized local variable is evaluated as part of an expression to print its value, resulting in undefined behavior:
Code Block | ||||
---|---|---|---|---|
| ||||
#include <iostream> void f() { int i; std::cout << i; } |
Compliant Solution
In this compliant solution, the object is initialized prior to printing its value:
Code Block | ||||
---|---|---|---|---|
| ||||
#include <iostream> void f() { int i = 0; std::cout << i; } |
Noncompliant Code Example
In this noncompliant code example, an int *
object is allocated by a new-expression, but the memory is points to is not initialized. The object's pointer value, and the value it points to are printed to the standard output stream. Printing the pointer value is well-defined, but attempting to print the value pointed to yields an indeterminate value, resulting in undefined behavior.
Code Block | ||||
---|---|---|---|---|
| ||||
#include <iostream> void f() { int *i = new int; std::cout << i << ", " << *i; } |
Compliant Solution
In this compliant solution, the memory is properly initialized prior to printing its value:
Code Block | ||||
---|---|---|---|---|
| ||||
#include <iostream> void f() { int *i = new int; *i = 12; std::cout << i << ", " << *i; } |
Noncompliant Code Example
In this noncompliant code example, the class member variable C
is not initialized by the default constructor. Despite the local variable o
being default-initialized, the use of C
within the call to S::f()
results in the use of an indeterminate value.
Code Block | ||||
---|---|---|---|---|
| ||||
class S { int C; public: int f(int I) const { return I + C; } }; void f() { S o; int i = o.f(10); } |
Compliant Solution
In this compliant solution, S
is given a default constructor that initializes the class member variable C
:
Code Block | ||||
---|---|---|---|---|
| ||||
class S { int C; public: S() : C(0) {} int f(int I) const { return I + C; } }; void f() { S o; int i = o.f(10); } |
Risk Assessment
Reading uninitialized variables is undefined behavior and can result in unexpected program behavior. In some cases, these security flaws may allow the execution of arbitrary code.
Reading uninitialized variables for creating entropy is problematic, because these memory accesses can be removed by compiler optimization. VU#925211 is an example of a vulnerability caused by this coding error.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
EXP53-CPP | High | Probable | Medium | P12 | L1 |
Automated Detection
Tool | Version | Checker | Description |
---|---|---|---|
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
Bibliography
[ISO/IEC 14882-2014] | 8.5, "Initializers" Clause 5, "Expressions" 5.3.4, "New" 12.6.2, "Initializing Bases and Members" |
[Lockheed Martin 05] | Rule 142, "All variables shall be initialized before use" |