Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 44 Next »

The results of allocating zero bytes of memory are implementation dependent. According to C99 Section 7.20.3 ISO/IEC 9899-1999:

If the size of the space requested is zero, the behavior is implementation defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object.

This includes all three standard memory allocation functions: malloc(), calloc(), and realloc(). In cases where the memory allocation functions return a non-NULL pointer, using this pointer results in undefined behavior. Typically these pointer refer to a zero-length block of memory consisting entirely of control structures. Overwriting these control structures will damage the data structures used by the memory manager.

malloc()

Non-Compliant Code Example

The result of calling malloc(0) to allocate 0 bytes is implementation defined. In this example, a dynamic array of integers is allocated to store s elements. However, if s is zero, the call to malloc(s) may return a reference to a block of memory of size 0 rather than NULL. When data is copied to this location, a heap-buffer overflow occurs.

/* ... */
list = malloc(sizeof(int) * s);
if (list == NULL) {
  /* Handle Allocation Error */
}
/* Continue Processing list */
/* ... */

Compliant Code Example

To ensure that zero is never passed as a size argument to malloc(), a check must be made on s to ensure it is not zero. Note that this solution checks for numeric overflow [[INT32-C. Ensure that integer operations do not result in an overflow]].


if (s == 0) {
  /* Handle Error */
}
if (sizeof(int) > SIZE_MAX/s) {
   /* handle overflow */
}
list = malloc(sizeof(int) * s);
if (list == NULL) {
  /* Handle Allocation Error */
}
/* Continue Processing list */
/* ... */

realloc()

Non-Compliant Code Example

The realloc() function deallocates the old object returns a pointer to a new object of a specified size. If memory for the new object cannot be allocated, the realloc() function does not deallocate the old object and its value is unchanged. If the realloc() function returns NULL, failing to free the original memory will result in a memory leak. As a result, the following idiom is generally recommended for reallocating memory:

char *p2;
char *p = malloc(100);
/* ... */
if ((p2 = realloc(p, nsize)) == NULL) {
  if (p) free(p);
  p = NULL;
  return NULL;
}
p = p2;

However, this commonly recommended idiom has problems with zero length allocations. If the value of nsize in this example is 0, the standard allows the option of either returning a null pointer or returning a pointer to an invalid (e.g., zero-length) object. In cases where the realloc() function frees the memory but returns a null pointer, execution of the code in this example results in a double free.

Implementation Details

The realloc() function for gcc 3.4.6 with libc 2.3.4 returns a non-NULL pointer to a zero-sized object (the same as malloc(0)). However, the realloc() function for both Microsoft Visual Studio Version 7.1 and gcc version 4.1.0 return a null pointer, resulting in a double free on the call to free() in this example.

Compliant Code Example

Do not pass a size argument of zero to the realloc() function.

char *p2;
char *p = malloc(100);
/* ... */
if ( (nsize == 0) || (p2 = realloc(p, nsize)) == NULL) {
  if (p) free(p);
  p = NULL;
  return NULL;
}
p = p2;

Risk Assessment

Assuming that allocating zero bytes results in an error can lead to buffer overflows when zero bytes are allocated. Buffer overflows can be exploited by an attacker to run arbitrary code with the permissions of the vulnerable process.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

MEM04-A

3 (high)

2 (probable)

2 (medium)

P12

L1

Related Vulnerabilities

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

References

[[ISO/IEC 9899-1999]] Section 7.20.3, "Memory Management Functions"
[[Seacord 05]] Chapter 4, "Dynamic Memory Management"

  • No labels