Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

...

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.

...

Uninitialized automatic variables or dynamically allocated memory has indeterminate valuevalues, 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); it can cause a program to behave in an unexpected manner and provide an avenue for attack. 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.

...

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.

...

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.

Code Block
bgColor#FFCCCC
langc
#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;
}

...

Code Block
bgColor#ffcccc
langc
#include <stdio.h>
enum { BUFFERSIZE = 24 }; 
void report_error(const char *msg) {
  enumconst { BUFFERSIZE = 24 };
  const char *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 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:

Code Block
bgColor#ccccff
langc
#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_log);
  printf("%s\n", buffermsg))
    printf("%s\n", buffer);
  else
    puts("Unknown error");
}

Compliant Solution (Uninitialized Local)

...

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.

Code Block
bgColor#FFCCCC
langc
#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);
}

...

Code Block
bgColor#ccccff
langc
#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())

...

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 undefined behavior.

Code Block
bgColor#FFCCCC
langc
#include <stdlib.h>

#include <stdio.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]);
  }
}

...

Code Block
bgColor#ccccff
langc
#include <stdlib.h>
#include <stdio.h> 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) {
    for (size_t i = memset(ret + old_count, 0, (new_count - old_count;
         i < new_count; ++i) {
      ret[i] = 0;
    } * sizeof(int));
  }
 
  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, OLD_SIZE, NEW_SIZE);
  if (0 == array) {
    /* Handle error */
  }
 
  for (size_t i = 0; i < NEW_SIZE; ++i) {
    printf("%d ", array[i]);
  }
}

...

EXP33-EX1: Reading uninitialized memory by an lvalue 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 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.

...

CERT C Secure Coding StandardMSC00-C. Compile cleanly at high warning levels
MSC01-C. Strive for logical completeness
CERT C++ Secure Coding StandardEXP33-CPP. Do not reference uninitialized memory
ISO/IEC TR 24772:2013Initialization of Variables [LAV]
ISO/IEC TS 17961Referencing uninitialized memory [uninitref]
MITRE CWECWE-119, Failure to constrain operations Improper Restriction of Operations within the bounds of an allocated memory bufferBounds of a Memory Buffer
CWE-665, Incorrect or incomplete initializationImproper Initialization

Bibliography

[Flake 2006] 
[ISO/IEC 9899:2011]Subclause 6.7.9, "Initialization"
Subclause 6.2.6.1, "General"
Subclause 6.3.2.1, "Lvalues, Arrays, and Function Designators"
[Mercy 2006] 
[Wang 2012]"More Randomness or Less"
[xorl 2009]"CVE-2009-1888: SAMBA ACLs Uninitialized Memory Read"

...