C library functions that make changes to arrays or objects take at least two arguments: a pointer to the array or object and an integer indicating the number of elements or bytes to be manipulated. If improper Supplying arguments are supplied to such a function , it might cause the function to form a pointer that does not point into or just past the end of the object, resulting in undefined behavior.

The C Standard identifies the following distinct situations in which undefined behavior (UB) can arise as a result of invalid pointer operations:

...

UB

...

Description

...

109

...

Annex J of the C Standard [ISO/IEC 9899:2011] states that it is undefined behavior if the "pointer passed to a library function array parameter does not have a value such that all address computations and object accesses are valid

...

" (see undefined behavior 109).

...

For the purposes of this rule, the element count of a pointer is the size of the object to which it points, expressed by the number of elements that are valid to access.

In the following code,

int arr[5];
int *p = arr;

unsigned char *p2 = (unsigned char *)arr;
unsigned char *p3 = arr + 2;
void *p4 = arr;

the element count of the pointer p is sizeof(arr) / sizeof(arr[0]), that is, 5. The element count of the pointer p2 is sizeof(arr), that is, 20, on platforms implementations where sizeof(int) == 4. The element count of the pointer p3 is 12 on platforms implementations where sizeof(int) == 4, because p3 points two elements past the start of the array arr.  The element count of p4 is treated as though it were unsigned char * instead of void *, so it is the same as p2.

...

Pointer

...

+ Integer

The following standard library functions take a pointer argument and a size argument, with the constraint that the pointer must point to a valid memory object of at least the number of elements indicated by the size argument.

...

#include <string.h>
#include <wchar.h>
 
static const char str[] = "Hello world";
static const wchar_t w_str[] = L"Hello world";
void func(void) {
  char buffer[32];
  wchar_t w_buffer[32];
  memcpy(buffer, str, sizeof(str)); /* Compliant */
  wmemcpy(w_buffer, w_str, sizeof(w_str));
} /* Noncompliant */
}

Compliant Solution (Element Count)

When using functions that operate on pointed-to regions, programmers must always express the integer size in terms of the element count expected by the function. For instanceexample, memcpy() expects the element count expressed in terms of void *, but wmemcpy() expects the element count expressed in terms of wchar_t *.  Instead of using the sizeof operator, calls to functions that return the number of elements in the string are usedcalled, which matches the expected element count for the copy functions. In the case of this compliant solution, where the argument is an array A of type T, the expression sizeof(A) / sizeof(T), or equivalently sizeof(A) / sizeof(*A), can be used to compute the number of elements in the array.

#include <string.h>
#include <wchar.h>
 
static 

#include <string.h>
#include <wchar.h>
 
static const char str[] = "Hello world";
static const wchar_t w_str[] = L"Hello world";
void func(void) {
  char buffer[32];
  wchar_t w_buffer[32];
  memcpy(buffer, str, strlen(str) + 1);
  wmemcpy(w_buffer, w_str, wcslen(w_str) + 1);
} 

...

In this noncompliant code example, the element count of the array a is ARR_SIZE elements. Because memset() expects a byte count, the size of the array is scaled incorrectly by sizeof(int) instead of sizeof(floatlong), which can form an invalid pointer on architectures where sizeof(int) != sizeof(floatlong).

#include <string.h>
 
void f2(void) {
  const size_t ARR_SIZE = 4;
  floatlong a[ARR_SIZE];
  const size_t n = sizeof(int) * ARR_SIZE;
  void *p = a;

  memset(p, 0, n);
}

...

#include <string.h>
 
void f2(void) {
  const size_t ARR_SIZE = 4;
  floatlong a[ARR_SIZE];
  const size_t n = sizeof(a);
  void *p = a;

  memset(p, 0, n);
}

...

Two Pointers

...

+ One Integer

The following standard library functions take two pointer arguments and a size argument, with the constraint that both pointers must point to valid memory objects of at least the number of elements indicated by the size argument. 

...

Noncompliant Code Example (Two Pointers + One Integer)

In this noncompliant example, a diagnostic is required This code example is noncompliant because the value of n is not incorrectly computed correctly, allowing a possible write past the end of the object referenced by p:

#include <string.h>
 
void f4(char p[], const char *q) {
  const size_t n = sizeof(p); 
  if ((memcpy(p, q, n)) == p) {
    /* ... */
  }
}
;
}

This example also violates ARR01-C. Do not apply the sizeof operator to a pointer when taking the size of an array.

...

#include <string.h>
 
void f4(char p[], const char *q, size_t size_pn) {
  const size_t n = size_p; 
  if ((memcpymemcpy(p, q, n)) == p) {
    /* ... */
  }
}

...

;
}

One Pointer + Two Integers

The following standard library functions take a pointer argument and two size arguments, with the constraint that the pointer must point to a valid memory object containing at least as many bytes as the product of the two size arguments.

...

This noncompliant code example allocates a variable number of objects of type struct obj. The function checks that num_objs is small enough to prevent wrapping, in compliance with INT30-C. Ensure that unsigned integer operations do not wrap. The size of struct obj is assumed to be 8 16 bytes to account for padding to achieve the assumed alignment of long long. However, the padding is dependent typically depends on the target architecture as well as compiler settings, so this object size may be incorrect, resulting in an incorrect element count.

#include <stdint.h>
#include <stdio.h>
 
struct obj {
  char c;
  long intlong i;
};
 
void func(FILE *f, struct obj *objs, size_t num_objs) {
  const size_t obj_size = 816;
  if (num_objs > (SIZE_MAX / obj_size) ||
      num_objs != fwrite(objs, obj_size, num_objs, f)) {
    /* Handle error */
  }
}

...

#include <stdint.h>
#include <stdio.h>
 
struct obj {
  char c;
  intlong long i;
};
 
void func(FILE *f, struct obj *objs, size_t num_objs) {
  const size_t obj_size = sizeof *objs;
  if (num_objs > (SIZE_MAX / sizeof(*objs))obj_size) ||
      num_objs != fwrite(objs, sizeof(*objs),obj_size, num_objs, f)) {
    /* Handle error */
  }
}

...

In this noncompliant code example, the function f() calls fread() to read nitems of type wchar_t, each size bytes in size, into an array of BUFFER_SIZE elements, wbuf. However, the expression used to compute the value of nitems fails to account for the fact that, unlike the size of char, the size of wchar_t may be greater than 1. Consequently, fread() could attempt to form pointers past the end of wbuf and use them to assign values to nonexistent elements of the array. Such an attempt results in is undefined behavior (see undefined behavior 109).  A likely consequence of this undefined behavior is a buffer overflow. For a discussion of this programming error in the Common Weakness Enumeration database, see CWE-121, "Access of memory location after end of bufferStack-based Buffer Overflow," and CWE-805, "Buffer access with incorrect length valueAccess with Incorrect Length Value."

#include <stddef.h>
#include <stdio.h>

void f(FILE *file) {
  enum { BUFFER_SIZE = 1024 };
  wchar_t wbuf[BUFFER_SIZE];

  const size_t size = sizeof(*wbuf);
  const size_t nitems = sizeof(wbuf);

  size_t nread;

  nread = fread(wbuf, size, nitems, file);
  /* ... */
}

Compliant Solution (One Pointer + Two Integers)

...

#include <stddef.h>
#include <stdio.h>
 
void f(FILE *file) {
  enum { BUFFER_SIZE = 1024 };
  wchar_t wbuf[BUFFER_SIZE];

  const size_t size = sizeof(*wbuf);
  const size_t nitems = sizeof(wbuf) / size;

  size_t nread;

  nread = fread(wbuf, size, nitems, file);
}  /* ... */
}

Risk Risk Assessment

Depending on the library function called, an attacker may be able to use a heap or stack overflow vulnerability to run arbitrary code.

...

Related Vulnerabilities

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

CERT vulnerability 720951 note VU#720951 describes a vulnerability in OpenSSL versions 1.0.1 through 1.0.1f, popularly known as "Heartbleed." . For a fuller description of this vulnerability, see the Related Vulnerabilities section of INT04-C. Enforce limits on integer values originating from tainted sources.

...

Bibliography

...