Page History

Local, automatic variables can assume unexpected values if they are used read before they are initialized.  The C standard specifies, "The C Standard, 6.7.11, paragraph 11, specifies [ISO/IEC 9899:2024]

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

...

representation is indeterminate.

See " [ISO/IEC 9899:2011]. (See also undefined behavior 11 of Annex J.)

When local, automatic variables are stored on the program stack, for example, their values default In the common case, on implementations that make use of a program stack, this value defaults to whichever values are currently stored in stack memory. While uninitialized memory often contains zeroes, this is not guaranteed. On implementations that include trap representations, reading an uninitialized object of any type other than unsigned char (including int) may trigger a trap. (See undefined behavior 12 of Annex J.) Consequently, uninitialized memory can cause a program to behave in an unpredictable or unplanned manner, lead to undefined behavior and can provide an avenue for attack.

Additionally, memory allocated by functions, such as malloc(), should not be used before being initialized as its contents are indeterminate.

In most cases, compilers warn about uninitialized variables, discussed in MSC00-C. Compile cleanly at high warning levels. In other cases, compilers will completely optimize out the uninitialized variables.

Noncompliant Code Example

Additionally, some dynamic memory allocation functions do not initialize the contents of the memory they allocate.

Uninitialized automatic variables or dynamically allocated memory has indeterminate values, which for objects of some types, can be a trap representation. Reading such trap representations is undefined behavior; it can cause a program to behave in an unexpected manner and provide an avenue for attack. (See undefined behavior 10 and undefined behavior 12.)  In many cases, compilers issue a warning diagnostic message when reading uninitialized variables. (See MSC00-C. Compile cleanly at high warning levels for more information.)

Noncompliant Code Example (Return-by-Reference)

In this noncompliant code example, the set_flag() function is intended to set the variable parameter, sign to -1 when number is negative or 1_flag, to the sign of number. However, the programmer neglected to account for number being 0. If the case where number is equal to 0, then sign remains uninitialized. Because the local variable sign is uninitialized , assuming that the architecture makes use of a program stack, it uses whatever value is at that location in the program stack. This may lead to unexpected or otherwise incorrect program behaviorwhen 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 (sign_flagNULL == NULLsign_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;
}

Compilers Some compilers assume that when the address of an uninitialized variable is passed to a function, the variable is initialized within that function. Because compilers frequently fail to diagnose any resulting failure to initialize the variable, the programmer must apply additional scrutiny to ensure the correctness of the code.

...

This defect results from a failure to consider all possible data states. (See See MSC01-C. Strive for logical completeness for more information.) Once the problem is identified, it can be trivially repaired )

Compliant Solution (Return-by-Reference)

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

Note also that unless doing so is prohibitive for performance reasons, an additional defense-in-depth practice worth considering is to initialize local variables immediately after declaration. Although compilers and static analysis tools 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 of which is inaccessible to the tool.. Unless doing so is prohibitive for performance reasons, an additional defense-in-depth practice worth considering is to initialize local variables immediately after declaration.

void set_flag(int number, int *sign_flag) {
  if (sign_flagNULL == NULLsign_flag) {
    return;

  if (number >= 0) {}

  /* accountAccount for number being 0 */
  if  *sign_flag = 1;
  }
  else {
    assert(number < 0);(number >= 0) { 
    *sign_flag = 1;
  } else {
    *sign_flag = -1;
  }
}

int is_negative(int number) {
  int sign = 0;   /* initialize as a matter ofInitialize for defense-in-depth */

  set_flag(number, &sign);

  return sign < 0;
}

Noncompliant Code Example (Uninitialized Local)

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, on architectures making use of a program stack, it assumes the value already on the stack at this location, which is a pointer to the stack memory allocated to the password array. an indeterminate value is read. The sprintf() call copies data in password from the arbitrary location pointed to by the indeterminate error_log variable until a null byte is reached. If the length of the string stored in the password array is greater than the size of the buffer array, , which can result in a buffer overflow occurs.

#include <stdio.h>

#include <ctype.h>
#include <string.h>

int do_auth(void) {
  char *username;
  char *password;

  /* /* Get username and password from user, return -1 ifon invaliderror */
}

void report_error(constextern int do_auth(void);
enum { BUFFERSIZE = 24 }; 
void report_error(const char *msg) {
  const char *error_log;
  char buffer[24BUFFERSIZE];

  sprintf(buffer, "Error: %s", error_log);
  printf("%s\n", buffer);
}

int main(void) {
  if (do_auth() == -1) {
    report_error("Unable to login");
  }
  return 0;
}

Noncompliant Code Example (Uninitialized Local)

In this noncompliant code example, the report_error() function has been modified so that error_log is properly initialized.:

#include <stdio.h>
enum { BUFFERSIZE = 24 }; 
void report_error(const char *msg) {
  const char *error_log = msg;
  char buffer[24BUFFERSIZE];

  sprintf(buffer, "Error: %s", error_log);

  printf("%s\n", buffer);
}

This solution is still example remains problematic because a buffer overflow will occur if the null-terminated byte string referenced by msg is greater than 17 bytescharacters, including the NULL terminator. The solution also makes use of a "magic number," which should be avoided. (See DCL06-C. Use meaningful symbolic constants to represent literal values.)

Compliant Solution

In this solution, the magic number is abstracted, and the buffer overflow is eliminated.

null terminator. (See STR31-C. Guarantee that storage for strings has sufficient space for character data and the null terminator for more information.)

Compliant Solution (Uninitialized Local)

In this compliant solution, the buffer overflow is eliminated by calling the snprintf() function:

#include <stdio.h>
enum {max_buffer BUFFERSIZE = 24 };

void report_error(const char *msg) {
  const char *error_log = msg;
  char buffer[max_bufferBUFFERSIZE];

  if (0 < snprintf(buffer, sizeof(buffer)BUFFERSIZE, "Error: %s", error_logmsg));
    printf("%s\n", buffer);
}
  else
    puts("Unknown error");
}

Compliant Solution (Uninitialized Local)

A much simpler, less error-prone , and better performing compliant solution is shown hereto simply print the error message directly instead of using an intermediate buffer:

#include <stdio.h>
 
void report_error(const char *msg) {
  printf("Error: %s\n", msg);
}

Noncompliant Code Example (mbstate_t)

In the this noncompliant code example below, the function mbrlen() is passed the address of an automatic mbstate_t object that has not been properly initialized, leading to . This is undefined behavior . See undefined behavior 200 in Annex J of C11 [ISO/IEC 9899:2011]200 because mbrlen() dereferences and reads its third argument.

#include <string.h> 
#include <wchar.h>
 
void ffunc(const char *mbs) {
  size_t len;
  mbstate_t state;

  len = mbrlen(mbs, strlen(mbs), &state);

  /* ... */
}

Compliant Solution (mbstate_t)

Before being passed to a multibyte conversion function, an mbstate_t object must be either initialized to the initial conversion state or set to a value that corresponds to the most recent shift state by a prior call to a multibyte conversion function. The This compliant solution sets the mbstate_t object to the initial conversion state by setting it to all zeros.:

void f(const #include <string.h> 
#include <wchar.h>
 
void func(const char *mbs) {
  size_t len;
  mbstate_t state;

  memset(&state, 0, sizeof (state));
  len = mbrlen(mbs, strlen(mbs), &state);

  /* ... */
}

Noncompliant Code Example (POSIX, Entropy)

In this noncompliant code example described in "More Randomness or Less" [Wang 2012], the process idID, 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 Linux that utilized use uninitialized memory as a source of randomness. Although the unpredictable property of junk is desired, the problem here is that some compilers will actually entropy because the value stored in junk is indeterminate. However, because accessing an indeterminate 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.

struct timeval tv;
unsigned long junk;

gettimeofday(#include <time.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/time.h>
  
void func(void) {
  struct timeval tv;
  unsigned long junk;

  gettimeofday(&tv, NULL);
  srandom((getpid() << 16) ^ tv.tv_sec ^ tv.tv_usec ^ junk);
}

In security protocols that rely on unpredictability, such as RSA encryption, a loss in entropy results While operating systems like OS X 10.6 keep the junk value, other systems like OS X 10.7 or 10.8 do not. The same code, when viewed in machine assembly, optimizes out the junk value leaving only the time and process id. In security protocols that rely on unpredictability like RSA encryption, a loss in entropy results in a less secure system [Wang 2012].

Compliant Solution (POSIX, Entropy)

This can be solved by using a more reliable source for random number generation. This compliant solution uses the CPU clock in addition to the Real-Time clock to seed the random number generator.compliant solution seeds the random number generator by using the CPU clock and the real-time clock instead of reading uninitialized memory:

#include <time.h>
#include     
double cpu_time;
struct timeval tv;
unsigned long junk;

<unistd.h>
#include <stdlib.h>
#include <sys/time.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 ^ junkcpu_time); 

Risk Assessment

Accessing uninitialized variables generally leads to unexpected program behavior. In some cases, these types of flaws may allow the execution of arbitrary code.

Distributions derived from Debian, particularly VU#925211 in the OpenSSL package for Debian Linux, are said to reference uninitialized memory. One might say that uninitialized memory causes the vulnerability, but this is not entirely true. The original OpenSSL code uses uninitialized memory as an additional source of randomness to an already randomly generated key. This generates good keys, but also causes the code-auditing tools Valgrind and Purify to issue warnings. Debian tries to fix the warnings with two changes. One actually eliminates the uninitialized memory access, but the other weakens the randomness of the keys. Weakening the randomness makes the key more predictable and causes a loss of security.

Automated Detection

...

LDRA tool suite

...

57 D
69 D

...

Fully implemented.

...

Can detect violations of this rule, but will return false positives if the initialization was done in another function.

...

Can detect some   violations of this rule when the -Wuninitialized flag is used.

...

Automatically detects simple violations of this rule, although it may return some false positives. It may not catch more complex violations, such as initialization within functions taking uninitialized variables as arguments. It does catch the second noncompliant code example, and can be extended to catch the first as well.

...

Coverity Prevent

...

NO_EFFECT

...

Klocwork

...

UNINIT.HEAP.MIGHT
UNINIT.HEAP.MUST
UNINIT.STACK.ARRAY.MIGHT
UNINIT.STACK.ARRAY.MUST UNINIT.STACK.ARRAY.PARTIAL.MUST
UNINIT.STACK.MUST

...

}

Noncompliant Code Example (realloc())

The realloc() function changes the size of a dynamically allocated memory object. The initial size bytes of the returned memory object are unchanged, but any newly added space is uninitialized, and its value is indeterminate. As in the case of malloc(), accessing memory beyond the size of the original object is undefined behavior 181.

It is the programmer's responsibility to ensure that any memory allocated with malloc() and realloc() is properly initialized before it is used.

In this noncompliant code example, an array is allocated with malloc() and properly initialized. At a later point, the array is grown to a larger size but not initialized beyond what the original array contained. Subsequently accessing the uninitialized bytes in the new array is undefined behavior.

#include <stdlib.h>
#include <stdio.h>
enum { OLD_SIZE = 10, NEW_SIZE = 20 };
 
int *resize_array(int *array, size_t count) {
  if (0 == count) {
    return 0;
  }
 
  int *ret = (int *)realloc(array, count * sizeof(int));
  if (!ret) {
    free(array);
    return 0;
  }
 
  return ret;
}
 
void func(void) {
 
  int *array = (int *)malloc(OLD_SIZE * sizeof(int));
  if (0 == array) {
    /* Handle error */
  }
 
  for (size_t i = 0; i < OLD_SIZE; ++i) {
    array[i] = i;
  }
 
  array = resize_array(array, NEW_SIZE);
  if (0 == array) {
    /* Handle error */
  }
 
  for (size_t i = 0; i < NEW_SIZE; ++i) {
    printf("%d ", array[i]);
  }
}

Compliant Solution (realloc())

In this compliant solution, the resize_array() helper function takes a second parameter for the old size of the array so that it can initialize any newly allocated elements:

#include <stdlib.h>
#include <stdio.h> 
#include <string.h>

enum { OLD_SIZE = 10, NEW_SIZE = 20 };
 
int *resize_array(int *array, size_t old_count, size_t new_count) {
  if (0 == new_count) {
    return 0;
  }
 
  int *ret = (int *)realloc(array, new_count * sizeof(int));
  if (!ret) {
    free(array);
    return 0;
  }
 
  if (new_count > old_count) {
    memset(ret + old_count, 0, (new_count - old_count) * sizeof(int));
  }
 
  return ret;
}
 
void func(void) {
 
  int *array = (int *)malloc(OLD_SIZE * sizeof(int));
  if (0 == array) {
    /* Handle error */
  }
 
  for (size_t i = 0; i < OLD_SIZE; ++i) {
    array[i] = i;
  }
 
  array = resize_array(array, OLD_SIZE, NEW_SIZE);
  if (0 == array) {
    /* Handle error */
  }
 
  for (size_t i = 0; i < NEW_SIZE; ++i) {
    printf("%d ", array[i]);
  }
}

Exceptions

EXP33-C-EX1: Reading uninitialized memory by an lvalue of type unsigned char that could not have been declared with the register storage class does not trigger undefined behavior. The unsigned char type is defined to not have a trap representation, which allows for moving bytes without knowing if they are initialized. (See the C Standard, 6.2.6.1, paragraph 3.) The requirement that register could not have been used (not merely that it was not used) is because on some architectures, such as the Intel Itanium, registers have a bit to indicate whether or not they have been initialized. The C Standard, 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.

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

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 these coding errors 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.

Related Guidelines

Key here (explains table format and definitions)

CERT-CWE Mapping Notes

Key here for mapping notes

CWE-119 and EXP33-C

• Intersection( CWE-119, EXP33-C) = Ø

• EXP33-C is about reading uninitialized memory, but this memory is considered part of a valid buffer (on the stack, or returned by a heap function). No buffer overflow is involved.

CWE-676 and EXP33-C

• Intersection( CWE-676, EXP33-C) = Ø

• EXP33-C implies that memory allocation functions (e.g., malloc()) are dangerous because they do not initialize the memory they reserve. However, the danger is not in their invocation, but rather reading their returned memory without initializing it.

CWE-758 and EXP33-C

Independent( INT34-C, INT36-C, MSC37-C, FLP32-C, EXP33-C, EXP30-C, ERR34-C, ARR32-C)

CWE-758 = Union( EXP33-C, list) where list =

• Undefined behavior that results from anything other than reading uninitialized memory

CWE-665 and EXP33-C

Intersection( CWE-665, EXP33-C) = Ø

CWE-665 is about correctly initializing items (usually objects), not reading them later. EXP33-C is about reading memory later (that has not been initialized).

CWE-908 and EXP33-C

CWE-908 = Union( EXP33-C, list) where list =

• Use of uninitialized items besides raw memory (objects, disk space, etc)

New CWE-CERT mappings:

CWE-123 and EXP33-C

Intersection( CWE-123, EXP33-C) = Ø

EXP33-C is only about reading uninitialized memory, not writing, whereas CWE-123 is about writing.

CWE-824 and EXP33-C

EXP33-C = Union( CWE-824, list) where list =

• Read of uninitialized memory that does not represent a pointer

Bibliography

Related Vulnerabilities

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

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

Related Guidelines

CERT C++ Secure Coding Standard: EXP33-CPP. Do not reference uninitialized memory

ISO/IEC 9899:2011 Section 6.7.9, "Initialization"

ISO/IEC TR 17961 (Draft) Referencing uninitialized memory [uninitref]

ISO/IEC TR 24772 "LAV Initialization of variables"

Bibliography

...

...

Image Modified Image Modified Image Modified