Ignored function return value

Revision as of 08:38, 2 November 2008 by KirstenS (Talk | contribs)

Jump to: navigation, search


This article includes content generously donated to OWASP by Fortify.JPG.


ASDR Table of Contents



If a functions return value is not checked, it could have failed without any warning.





  • Integrity: The data which was produced as a result of a function could be in a bad state.

Exposure period



  • Languages: C or C++
  • Operating platforms: Any

Required resources




Likelihood of exploit


Risk Factors



Example 1: In C/C++


Example 2

Consider the following code:

	char buf[10], cp_buf[10];
	fgets(buf, 10, stdin);
	strcpy(cp_buf, buf);

The programmer expects that when fgets() returns, buf will contain a null-terminated string of length 9 or less. But if an I/O error occurs, fgets() will not null-terminate buf. Furthermore, if the end of the file is reached before any characters are read, fgets() returns without writing anything to buf. In both of these situations, fgets() signals that something unusual has happened by returning NULL, but in this code, the warning will not be noticed. The lack of a null terminator in buf can result in a buffer overflow in the subsequent call to strcpy().

Example 3

The following code does not check to see if memory allocation succeeded before attempting to use the pointer returned by malloc().

	buf = (char*) malloc(req_size);
	strncpy(buf, xfer, req_size);

The traditional defense of this coding error is:

"If my program runs out of memory, it will fail. It doesn't matter whether I handle the error or simply allow the program to die with a segmentation fault when it tries to dereference the null pointer."

This argument ignores three important considerations:

  1. Depending upon the type and size of the application, it may be possible to free memory that is being used elsewhere so that execution can continue.
  2. It is impossible for the program to perform a graceful exit if required. If the program is performing an atomic operation, it can leave the system in an inconsistent state.
  3. The programmer has lost the opportunity to record diagnostic information. Did the call to malloc() fail because req_size was too large or because there were too many requests being handled at the same time? Or was it caused by a memory leak that has built up over time? Without handling the error, there is no way to know.
  • In Java:

Although some Java members may use return values to state their status, it is preferable to use exceptions.

Related Attacks

Related Vulnerabilities

Related Controls

  • Implementation: Check all functions which return a value

Related Technical Impacts