Page History

Avoid excessive stack allocations, particularly in situations where the growth of the stack can be controlled or influenced by an attacker.

Non-Compliant Code Example

C99 includes support for variable-length arrays (VLAs) \[[ISO/IEC 9899:1999|AA. C References#ISO/IEC 9899-1999]\]. If the array length is derived from an untrusted data source, an attacker can cause the process to perform an excessive allocation on the stack.

See INT04-C. Enforce limits on integer values originating from tainted sources for more information on preventing attacker-controlled integers from exhausting memory.

Noncompliant Code Example

The C Standard includes support for variable length arrays (VLAs). If the array length is derived from an untrusted data source, an attacker can cause the process to perform an excessive allocation on the stack.

This noncompliant This non-compliant code example temporarily stores data read from a source file into a buffer. The buffer is allocated on the stack as a variable-length array a VLA of size bufsize. If bufsize can be controlled by a malicious user, this code can be exploited to cause a denial-of-service attack.:

int copy_file(FILE *src, FILE *dst, size_t bufsize) {
  char buf[bufsize];

  while (fgets(buf, bufsize, src)) {
    if (fputs(buf, dst) == EOF) {
      /* Handle Errorerror */
    }
  }

  return 0;
}

...

The BSD extension function {{alloca()}} behaves in a similar fashion to VLAs; its use is not recommended \[ [Loosemore 07|AA. C References#Loosemore 07]\] 2007].

Compliant Solution

This compliant solution replaces the variable-length array the VLA with a call to malloc(). If malloc() fails, the return value can be checked to prevent the program from terminating abnormally.

int copy_file(FILE *src, FILE *dst, size_t bufsize) {
  if (bufsize == 0) {
    /* Handle Errorerror */
  }
  char *buf = (char *)malloc(bufsize);
  if (!buf) {
    /* return -1;Handle error */
  }

  while (fgets(buf, bufsize, src)) {
    if (fputs(buf, dst) == EOF) {
      /* Handle Errorerror */
    }
  }
  /* ... */
  free(buf);
  return 0;
}

...

Noncompliant Code Example

Recursion can also lead to large stack allocations. Recursive functions must ensure they that they do not exhaust the stack due to excessive stack as a result of excessive recursions.

This non-compliant noncompliant implementation of the Fibonacci function uses recursion.:

unsigned long fib1(unsigned int n) {
  if (n == 0) {
    return 0;
  }
  else if (n == 1 || n == 2) {
    return 1;
  }
  else {
    return fib1(n-1) + fib1(n-2);
  }
}

The stack space needed grows exponentially The amount of stack space needed grows linearly with respect to the parameter n. Large values of n have been shown to cause abnormal program termination.

Compliant Solution

This implementation of the Fibonacci functions eliminates the use of recursion.:

unsigned long fib2(unsigned int n) {
  if (n == 0) {
    return 0;
  }
  else if (n == 1 || n == 2) {
    return 1;
  }

  unsigned long prev = 1;
  unsigned long cur = 1;

  unsigned int i;

  for (i = 3; i <= n; i++) {
    unsigned long tmp = cur;
    cur = cur + prev;
    prev = tmp;
  }

  return cur;
}

Because there is no recursion, the amount of stack space needed does not depend on the parameter n, greatly reducing the risk of stack overflow.

Risk Assessment

Program stacks are frequently used for convenient temporary storage , because allocated memory is automatically freed when the function returns. Generally, the operating system will grow grows the stack as needed. However, growing the stack can fail due to a fail because of a lack of memory or collision a collision with other allocated areas of the address space (depending on the architecture). When the stack is exhausted, the operating system may can terminate the program abnormally. This behavior can be exploited by , and an attacker to can cause a denial-of-service attack in situations where the attacker can attack if he or she can control or influence the amount of stack memory allocated.

Related Vulnerabilities

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

Automated Detection

...

Automated Detection

...

Related Vulnerabilities

Stack overflow has been implicated in Toyota unintended acceleration cases, where Camry and other Toyota vehicles accelerated unexpectedly.  Michael Barr testified at the trial that a stack overflow could corrupt the critical variables of the operating system, because they were located in memory adjacent to the top of the stack [Samek 2014].

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

Related Guidelines

Bibliography

...

Image Added Image Added Image Added

References

\[[ISO/IEC 9899:1999|AA. C References#ISO/IEC 9899-1999]\] Section 6.7.5.2, "Array declarators", Section 7.20.3, "Memory management functions"
\[[ISO/IEC PDTR 24772|AA. C References#ISO/IEC PDTR 24772]\] "GDL Recursion"
\[[Loosemore 07|AA. C References#Loosemore 07]\] [Section 3.2.5, "Automatic Storage with Variable Size"|http://www.gnu.org/software/libc/manual/html_mono/libc.html#Variable-Size-Automatic]
\[[MISRA 04|AA. C References#MISRA 04]\] Rule 16.2
\[[Seacord 05a|AA. C References#Seacord 05]\] Chapter 4, "Dynamic Memory Management"
\[[van Sprundel 06|http://ilja.netric.org/files/Unusual%20bugs.pdf]\] "Stack Overflow"

MEM04-C. Do not perform zero length allocations      08. Memory Management (MEM)       MEM06-A. Ensure that sensitive data is not written out to disk