Page History

Integer values The types of integer expressions used as a size argument arguments to malloc(), calloc(), or reallocrealloc(), or aligned_alloc() must be valid and large enough to contain the type of object have sufficient range to represent the size of the objects to be stored. If size arguments are incorrect , or can be manipulated by an attacker, then a buffer overflow may occur. Incorrect size arguments, inadequate range checking, integer overflow, or truncation can result in the allocation of an inadequately sized buffer. The programmer must ensure that size arguments to memory allocation functions allocate sufficient memory.

Non-Compliant Code Example 1

.

Typically, the amount of memory to allocate will be the size of the type of object to allocate. When allocating space for an array, the size of the object will be multiplied by the bounds of the array. When allocating space for a structure containing a flexible array member, the size of the array member must be added to the size of the structure. (See MEM33-C. Allocate and copy structures containing a flexible array member dynamically.) Use the correct type of the object when computing the size of memory to allocate.

STR31-C. Guarantee that storage for strings has sufficient space for character data and the null terminator is a specific instance of this rule.

Noncompliant Code Example (Pointer)

In this noncompliant code example, inadequate space is allocated for a struct tm object because the size of the pointer is being used to determine the size of the pointed-to object:In this non-compliant code example, cBlocks is multiplied by 16 and the result is stored in the unsigned long long int alloc.

void* AllocBlocks(size_t cBlocks) {
  if (cBlocks == 0) return NULL;
  unsigned long long alloc = cBlocks * 16;
  return (alloc < UINT_MAX)
#include <stdlib.h>
#include <time.h>
 
struct tm *make_tm(int year, int mon, int day, int hour,
                   ? malloc(cBlocks * 16)int min, int sec) {
  struct   : NULL;
}

If size_t is represented as a 32-bit unsigned value and unsigned long long represented as a 64-bit unsigned value, for example, the result of this multiplication can still overflow because the actual multiplication is a 32-bit operation. As a result, the value stored in alloc will always be less than UINT_MAX.

If both size_t and unsigned long long types are represented as a 64-bit unsigned value, the result of the multiplication operation may not be representable as an unsigned long long value.

Compliant Solution 1

tm *tmb;
  tmb = (struct tm *)malloc(sizeof(tmb));
  if (tmb == NULL) {
    return NULL;
  }
  *tmb = (struct tm) {
    .tm_sec = sec, .tm_min = min, .tm_hour = hour,
    .tm_mday = day, .tm_mon = mon, .tm_year = year
  };
  return tmb;
}

Compliant Solution (Pointer)

 In this compliant solution, the correct amount of memory is allocated for the struct tm object. When allocating  space for a single object, passing the (dereferenced) pointer type to the sizeof operator is a simple way to allocate sufficient memory. Because the sizeof operator does not evaluate its operand, dereferencing an uninitialized or null pointer in this context is well-defined behavior Wiki MarkupMake sure that integer values passed as size arguments to memory allocation functions are valid and have not been corrupted due to integer overflow, truncation, or sign error \[[Integers (INT)|04. Integers (INT)]\]. In the following example, the {{multsize_t()}} function multiples two values of type {{size_t}} and sets {{errno}} to a non-zero value if the resulting value cannot be represented as a {{size_t}}.

void *AllocBlocks(size_t cBlocks) {
  size_t alloc;

  if (cBlocks == 0) return NULL;
  alloc = multsize_t(cBlocks, 16);
  if (errno) {
   #include <stdlib.h>
#include <time.h>
 
struct tm *make_tm(int year, int mon, int day, int hour,
                   int min, int sec) {
  struct tm *tmb;
  tmb = (struct tm *)malloc(sizeof(*tmb));
  if (tmb == NULL) {
    return NULL;
   }
  else*tmb {
=    return malloc(alloc);
  }
} /* end AllocBlocks */

Non-Compliant Code Example 2

In this non-compliant code example, the string referenced by str and the string length represented by len orginate from untrusted sources. The length is used to perform a memcpy() into the fixed size static array buf. The len variable is guaranteed to be less than BUFF_SIZE. However, because len is declared as an int it could have a negative value that would bypass the check. The memcpy() function implicitly converts len to an unsigned size_t type, and the resulting operation results in a buffer overflow.

int len;
char *str;
char buf[BUFF_SIZE];

/* ... */
if (len < BUFF_SIZE){
  memcpy(buf, str, len);
}
/* ... */

Compliant Solution 2

In this compliant solution, len is declared as a size_t to there is no possibility of this variable having a negative value and bypassing the range check.

size_t len;
char *str;
char buf[BUFF_SIZE];

/* ... */
if (len < BUFF_SIZE){
  memcpy(buf, str, len);
}
/* ... */

Non-Compliant Code Example 3

In this example, an array of long integers is allocated and assigned to {{p}}. However, {{sizeof(int)}} is used to size the allocated memory. If {{sizeof(long)}} is larger than {{sizeof(int)}}, then an insufficient amount of memory will be allocated. This example also checks for unsigned numeric overflow in compliance with \[[INT32-C|INT32-C. Ensure that integer operations do not result in an overflow]\].

(struct tm) {
    .tm_sec = sec, .tm_min = min, .tm_hour = hour,
    .tm_mday = day, .tm_mon = mon, .tm_year = year
  };
  return tmb;
}

Noncompliant Code Example (Integer)

In this noncompliant code example, an array of long is allocated and assigned to p. The code attempts to check for unsigned integer overflow in compliance with INT30-C. Ensure that unsigned integer operations do not wrap and also ensures that len is not equal to zero. (See MEM04-C. Beware of zero-length allocations.) However, because sizeof(int) is used to compute the size, and not sizeof(long), an insufficient amount of memory can be allocated on implementations where sizeof(long) is larger than sizeof(int), and filling the array can cause a heap buffer overflow.

#include <stdint.h>
#include <stdlib.h>
 

void function(size_t len) {
   long *p;
   if (len == 0 || len > SIZE_MAX / sizeof(long)) {
      /* handleHandle overflow */
   }
   p = (long *)malloc(len * sizeof(int));
   if (p == NULL) {
      /* Handle  handle error */
   }
   /* ... */
   free(p);
}

Compliant Solution

...

(Integer)

This compliant solution uses To correct this example, sizeof(long) is used to  to correctly size the memory allocation.:

#include <stdint.h>
#include <stdlib.h>

void function(size_t len) {
   long *p;
   if (len == 0 || len > SIZE_MAX / sizeof(long)) {
      /* handleHandle overflow */
   }
   p = (long *)malloc(len * sizeof(long));
   if (p == NULL) {
      /*   handleHandle error */
   }
   /* ... */
   free(p);
}

Compliant Solution (Integer)

Alternatively, sizeof(*p) can  can be used to properly size the allocation:

#include <stdint.h>
#include <stdlib.h>
 

void function(size_t len) {
   long *p;
   if (len == 0 || len > SIZE_MAX / sizeof(*p)) {
      /* handleHandle overflow */
   }
   p = (long *)malloc(len * sizeof(*p));
   if (p == NULL) {
      /*   handleHandle error */
   }
   /* ... */
   free(p);
}

Risk Assessment

Providing invalid size arguments to memory allocation functions can lead to buffer overflows and the execution of arbitrary code with the permissions of the vulnerable process.

Automated Detection

...

Automated Detection

if (a < SIZE_MAX / b && a > 0) ...

...

Related Vulnerabilities

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

References

the CERT website.

Related Guidelines

Key here (explains table format and definitions)

CERT-CWE Mapping Notes

Key here for mapping notes

CWE-680 and MEM35-C

Intersection( INT32-C, MEM35-C) = Ø

CWE-680 = Union( MEM35-C, list) where list =

• Overflowed buffers with inadequate sizes not produced by integer overflow

CWE-467 and MEM35-C

CWE-467 = Subset( MEM35-C)

CWE-789 and MEM35-C

Intersection( MEM35-C, CWE-789) =

• Insufficient memory allocation on the heap

MEM35-C – CWE-789 =

• Insufficient memory allocation with trusted value but incorrect calculation

CWE-789 - MEM35-C =

• Sufficient memory allocation (possibly over-allocation) with untrusted value

CWE-120 and MEM35-C

Intersection( MEM35-C, CWE-120) = Ø

CWE-120 specifically addresses buffer overflow operations, which occur in the context of string-copying. MEM35-C specifically addresses allocation of memory ranges (some of which may be for subsequent string copy operations).

Consequently, they address different sections of code, although one (or both) may be responsible for a single buffer overflow vulnerability.

CWE-131 and MEM35-C

• Intersection( INT30-C, MEM35-C) = Ø

• CWE-131 = Union( MEM35-C, list) where list =

• Miscalculating a buffer for a non-heap region (such as a variable-length array)

Bibliography

...

Image Added Image Added Image Added Wiki Markup\[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\] Section 7.20.3, "Memory Management Functions" \[[Seacord 05|AA. C References#Seacord 05]\] Chapter 4, "Dynamic Memory Management," and Chapter 5, "Integer Security" \[Coverity 07\] Coverity Prevent User's Manual (3.3.0) (2007).