Page History

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

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

See undefined behavior 11.

In the common case of When local, automatic variables being are stored on the program stack, for example, their values default to whichever values are currently stored in stack memory.

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

Uninitialized automatic variables or dynamically allocated memory has has indeterminate valuevalues, which for objects of some types, can be a trap representation. Reading uninitialized memory such trap representations is undefined behavior (see undefined behavior 10 and undefined behavior 12); it can cause a program to behave in an unexpected manner and provide an avenue for attack. In . (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 parameter, sign_flag, to the sign of number. However, the programmer neglected to account for the case where number is equal to 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.

...

This defect results from a failure to consider all possible data states. (See MSC01-C. Strive for logical completeness for more information.)

Compliant Solution (Return-by-Reference)

...

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.

#include <stdio.h>

/* Get username and password from user, return -1 on error */
extern int do_auth(void);
enum { BUFFERSIZE = 24 }; 
void report_error(const char *msg) {
  enum { BUFFERSIZE = 24 };
  const char *error_log;
  char buffer[BUFFERSIZE];

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

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

...

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

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

This example is still remains problematic because a buffer overflow will occur if the null-terminated byte string referenced by msg is greater than 17 characters, including the null terminator. For more information, see (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 using calling the snprintf() function:

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

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

Compliant Solution (Uninitialized Local)

...

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. This compliant solution sets the mbstate_t object to the initial conversion state by setting it to all zeros.:

#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);
}

...

In this noncompliant code example described 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 Linux that use uninitialized memory as a source of 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.

#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);
}

...

#include <time.h>
#include <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 ^ cpu_time);
}

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 results in 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 does not initialize any values initialized beyond what the original array contained. Subsequently , accessing the uninitialized values bytes in the new array results in 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) {
 
  enum { OLD_SIZE = 10, NEW_SIZE = 20 };
 
  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]);
  }
}

...

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                 size_t new_count) 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) {
    for (size_t i = memset(ret + old_count, 0, (new_count - old_count) * sizeof(int));
  }
 
  return ret;
}
 
void  i < new_count; ++i) {
      ret[i] = 0;func(void) {
 
  int *array = (int *)malloc(OLD_SIZE * sizeof(int));
  if (0 == array) {
    }
/* Handle }
error */
  return ret;
}
 
void  for func(void) {
  enum {(size_t i = 0; i < OLD_SIZE = 10, NEW_SIZE = 20 };
 
  int *; ++i) {
    array[i] = i;
  }
 
  array = resize_array(int *)malloc(array, OLD_SIZE * sizeof(int), NEW_SIZE);
  if (0 == array) {
    /* Handle error */
  }
 
  for (size_t i = 0; i < OLDNEW_SIZE; ++i) {
    array[i] = i;
  }
 
  array = resize_array(array, OLD_SIZE, NEW_SIZEprintf("%d ", array[i]);
  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 does not trigger 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 (see , which allows for moving bytes without knowing if they are initialized. (See the C Standard, subclause 6.2.6.1, paragraph 3), which allows for moving bytes without knowing if they are initialized. However, .) 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, subclause 66.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 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 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.

Related Guidelines

Bibliography

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

...

...

Image Modified Image Modified Image Modified