Page History

Local, automatic variables assume unexpected values if they are read before they are initialized. The C++ Standard, [dcl.init], paragraph 12 [ISO/IEC 14882-2014], states the following: 

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.

...

As a result, objects of type T with automatic or dynamic storage duration must be explicitly initialized before having their value read as part of an expression unless T is a class type or an array thereof or is 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 technique can be used to implement copy operations such as 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(), and so on) 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 before having their value read.

Reading uninitialized variables for creating entropy is problematic because these memory accesses can be removed by compiler optimization.  VU925211 is an example of a vulnerability caused by this coding error [VU#925211].

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:.

#include <iostream>
 
void f() {
  int i;
  std::cout << i;
}

...

In this compliant solution, the object is initialized prior to printing its value:.

#include <iostream>
 
void f() {
  int i = 0;
  std::cout << i;
}

...

In this compliant solution, the memory is properly initialized direct-initialized to the value 12 prior to printing its value:.

#include <iostream>
 
void f() {
  int *i = new int;
  *i = 12(12);
  std::cout << i << ", " << *i;
}

Initialization of an object produced by a new-expression is performed by placing (possibly empty) parenthesis or curly braces after the type being allocated. This causes direct initialization of the pointed-to object to occur, which will zero-initialize the object if the initialization omits a value, as illustrated by the following code.

int *i = new int(); // zero-initializes *i
int *j = new int{}; // zero-initializes *j
int *k = new int(12); // initializes *k to 12
int *l = new int{12}; // initializes *l to 12

Noncompliant Code Example

In this noncompliant code example, the class member variable C c is not explicitly initialized by a ctor-initializer in the default constructor. Despite the local variable o s being default-initialized, the use of C c within the call to S::f() results in the evaluation of an object with indeterminate value, resulting in undefined behavior.

class S {
  int Cc;
 
public:
  int f(int Ii) const { return Ii + Cc; }
};
 
void f() {
  S os;
  int i = os.f(10);
}

Compliant Solution

In this compliant solution, S is given a default constructor that initializes the class member variable C:c.

class S {
  int Cc;
 
public:
  S() : Cc(0) {}
  int f(int Ii) const { return Ii + Cc; }
};
 
void f() {
  S os;
  int i = o.f(10);
}

Noncompliant Code Example

...

s

...

#include <iostream>
#include <string>

void g(std::string &&v) {
  std::cout << v << std::endl;
}

void f() {
  std::string s;
  for (unsigned i = 0; i < 10; ++i) {
    s.append(1, static_cast<char>('0' + i));
    g(std::move(s));
  }
}

Implementation Details

Some standard library implementations may implement the short string optimization (SSO) when implementing std::string. In such implementations, strings under a certain length are stored in a character buffer internal to the std::string object (avoiding an expensive heap allocation operation). However, such an implementation might not alter the original buffer value when performing a move operation. When the noncompliant code example is compiled with Clang 3.7 using libc++, the following output is produced:

0
01
012
0123
01234
012345
0123456
01234567
012345678
0123456789

Compliant Solution

...

.

...

#include <iostream>
#include <string>

void g(std::string &&v) {
  std::cout << v << std::endl;
}

void f() {
  for (unsigned i = 0; i < 10; ++i) {
    std::string s(1, static_cast<char>('0' + i));
    g(std::move(s));
  }
}

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.

Automated Detection

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

Bibliography

...

...

Image Modified Image Modified Image Modified