Page History

Local, automatic variables assume unexpected values if they are read before they are initialized. The C Standard, subclause 6.7.9, paragraph 10 specifies 10, specifies [ISO/IEC 9899:2011]:

If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate.

...

In the common case of local, automatic variables being stored on the program stack, their values default to whichever values are currently stored in stack memory. Uninitialized memory has indeterminate value, which for objects of some types can be a trap representation. Reading uninitialized memory is undefined behavior (see undefined behavior 10 and undefined behavior 12 in Annex J of the C Standard); it can cause a program to behave in an unexpected manner and provide an avenue for attack.

...

In most cases, compilers issue a warning diagnostic message when reading uninitialized variables.   See MSC00-C. Compile cleanly at high warning levels for more information.

...

In this noncompliant code example, the set_flag() function is intended to set the parameter, sign_flag, to the sign of number. However, the programmer neglected to account for number being 0. Because the local variable sign is uninitialized when calling set_flag(), and is never written to by set_flag(), the comparison operation exhibits undefined behavior when reading sign.

void set_flag(int number, int *sign_flag) {
  if (NULL == sign_flag) {
    return;
  }

  if (number > 0) {
    *sign_flag = 1;
  } else if (number < 0) {
    *sign_flag = -1;
  }
}

int is_negative(int number) {
  int sign;
  set_flag(number, &sign);
  return sign < 0;
}

...

This compliant solution trivially repairs the problem by accounting for the possibility that number can be equal to 0.

Although compilers and static analysis tools often detect uses of uninitialized variables when they have access to the source code, diagnosing the problem is difficult or impossible when either the initialization or the use takes place in object code for which the source code is inaccessible. Unless doing so is prohibitive for performance reasons, an additional defense-in-depth practice worth considering is to initialize local variables immediately after declaration.

...

In this noncompliant code example, the programmer mistakenly fails to set the local variable error_log to the msg argument in the report_error() function [Mercy 2006]. Because error_log has not been initialized, reading it results in undefined behavior, and an indeterminate value is read. The sprintf() call copies data from the arbitrary location pointed to by the indeterminate error_log variable until a null byte is reached, which can result in a buffer overflow.

...

In this noncompliant code example, the function mbrlen() is passed the address of an automatic mbstate_t object that has not been properly initialized. This leads to undefined behavior, because mbrlen() dereferences and reads its third argument. See undefined behavior 200 in Annex J of the C Standard.

...

In this noncompliant code example described by in "More Randomness or Less" [Wang 2012], the process ID, time of day, and uninitialized memory junk is used to seed a random number generator. This behavior is characteristic of some distributions derived from Debian that use uninitialized memory as a source of entropy because the value stored in junk is indeterminate. However, because accessing accessing indeterminate values value is undefined behavior, compilers may optimize out the uninitialized variable access completely, leaving only the time and process ID and resulting in a loss of desired entropy.

...

#include <time.h>
#include <unistd.h>
#include <stdlib.h>

void func(void) {     
  double cpu_time;
  struct timeval tv;

  cpu_time = ((double) clock()) / CLOCKS_PER_SEC;
  gettimeofday(&tv, NULL);
  srandom((getpid() << 16) ^ tv.tv_sec ^ tv.tv_usec);
}

Exceptions

EXP33-EX0EX1: Reading uninitialized memory of type unsigned char does not trigger undefined behavior. The unsigned char type is defined to not have a trap representation (see the C Standard, subclause 6.2.6.1, paragraph 3), which allows for moving bytes without knowing if they are initialized. However, on some architectures, such as the Intel Itanium, registers have a bit to indicate whether or not they have been initialized. The C Standard, subclause 6.3.2.1, paragraph 2, allows such implementations to cause a trap for an object that never had its address taken and is stored in a register if such an object is referred to in any way.

...

Reading uninitialized variables is 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.

...

...

CVE-2009-1888 results from a violation of this rule. Some versions of SAMBA (up to 3.3.5) call a function that takes in two potentially uninitialized variables involving access rights. An attacker can exploit this to bypass the access control list and gain access to protected files [xorl 2009].

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

...

...