Page History

Many functions require the allocation of multiple objects. Failing and returning somewhere in the middle of this function without freeing all of the allocated memory could produce a memory leak. It is a common error to forget to free one (or all) of the objects in this manner, so a goto-chain is the simplest and cleanest way to organize exits when order is preserved.

Noncompliant Code Example

In this noncompliant example, exit code is written for every instance in which the function can terminate prematurely. Notice how failing to allocate obj3 produces a memory leak.

int do_something(void){
  // ... definitions ...

  obj1 = malloc(...allocate_object();
  if (!obj1 == NULL){
    return -1;
  }

  obj2 = malloc(...allocate_object();
  if (!obj2 == NULL){
    free(obj1);
    return -1;
  }

  obj3 = malloc(...allocate_object();
  if (!obj3 == NULL){
    free(obj2);
    return -1; // Forgot to free obj1 -- Memory leak
  }

  // ... more code ...
}

Notice how there is a memory leak if obj3 cannot be allocated. This is also just a small example; in much larger examples, errors like this would be even harder to detect. Hence, the

Compliant Solution

In this revised version, we have used a goto-chain in replacement of each individual return segment. If there is no error, control flow will fall through to the SUCCESS label and return 0. .

Compliant Solution

In the case of an error, control flow will jump to the proper failure label and the appropriate memory will be freed before returning an error.

int do_something(void){
  // ... definitions ...

  obj1 = malloc(...allocate_object();
  if (!obj1 == NULL){
    goto FAIL_OBJ1;
  }

  obj2 = malloc(...allocate_object();
  if (!obj2 == NULL){
    goto FAIL_OBJ2;
  }

  obj3 = malloc(...allocate_object();
  if (!obj3 == NULL){
    goto FAIL_OBJ3;
  }


  // ... more code ...


SUCCESS:     // Return normally
  return 0;

FAIL_OBJ3:   // Otherwise, free objects in order
  free(obj2);

FAIL_OBJ2:
  free(obj1);

FAIL_OBJ1:
  return -1;
}

This code is guaranteed to clean up properly whenever an allocation fails.  It is cleaner and prevents The benefits of this method are that the code is cleaner and we prevent the rewriting of similar code upon every function error.

References

\[[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"

Related Vulnerabilities

Note that this method does not only prevent leakage from memory allocation; the same logic could be used to ensure the closure of files and pipes, for example. Similarly, in C++, this would also apply more generally to constructors and destructors.