Unchecked Return Value
Draft Base
Structure: Simple
Description
This vulnerability occurs when a program fails to verify the result of a function or method call, allowing it to continue execution without detecting errors or unexpected conditions.
Developers often assume critical operations will always succeed or that their failure is inconsequential. However, attackers can exploit these unchecked return values by forcing functions to fail or return unexpected data, tricking the application into operating in an insecure, unintended state. For instance, if a privilege-dropping function fails silently, the program continues running with elevated access, creating a severe security gap. To prevent this, treat every function call that can impact security or stability as having a potential failure state. Always validate return codes, especially for security-critical operations like memory allocation, file operations, authentication checks, and system configuration changes. Implementing consistent error handling ensures the application responds safely to unexpected conditions rather than proceeding with flawed assumptions.
Common Consequences 1
Scope: AvailabilityIntegrity
Impact: Unexpected StateDoS: Crash, Exit, or Restart
An unexpected return value could place the system in a state that could lead to a crash or other unintended behaviors.
Detection Methods 1
Automated Static AnalysisHigh
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)Potential Mitigations 4
Phase: Implementation
Check the results of all functions that return a value and verify that the value is expected.
Effectiveness: High
Phase: Implementation
For any pointers that could have been modified or provided from a function that can return NULL, check the pointer for NULL before use. When working with a multithreaded or otherwise asynchronous environment, ensure that proper locking APIs are used to lock before the check, and unlock when it has finished [REF-1484].
Phase: Implementation
Ensure that you account for all possible return values from the function.
Phase: Implementation
When designing a function, make sure you return a value or throw an exception in case of an error.
Demonstrative Examples 10
ID : DX-7
Consider the following code segment:Code Example:
Bad
C
cThe 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().
ID : DX-114
In the following example, it is possible to request that memcpy move a much larger segment of memory than assumed:Code Example:
Bad
C
c/* if chunk info is valid, return the size of usable memory,*
cIf returnChunkSize() happens to encounter an error it will return -1. Notice that the return value is not checked before the memcpy operation (Unchecked Return Value), so -1 can be passed as the size argument to memcpy() (Buffer Access with Incorrect Length Value). Because memcpy() assumes that the value is unsigned, it will be interpreted as MAXINT-1 (Signed to Unsigned Conversion Error), and therefore will copy far more memory than is likely available to the destination buffer (Out-of-bounds Write, Access of Memory Location After End of Buffer).
ID : DX-8
The following code does not check to see if memory allocation succeeded before attempting to use the pointer returned by malloc().Code Example:
Bad
C
cThe 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 allow the program to die with a segmentation fault when it tries to dereference the null pointer." This argument ignores three important considerations:
- 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.
- 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.
- 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.
ID : DX-9
The following examples read a file into a byte array.Code Example:
Bad
C#
c#Code Example:
Bad
Java
javaThe code loops through a set of users, reading a private data file for each user. The programmer assumes that the files are always 1 kilobyte in size and therefore ignores the return value from Read(). If an attacker can create a smaller file, the program will recycle the remainder of the data from the previous user and treat it as though it belongs to the attacker.
ID : DX-10
The following code does not check to see if the string returned by getParameter() is null before calling the member function compareTo(), potentially causing a NULL dereference.Code Example:
Bad
Java
javaThe following code does not check to see if the string returned by the Item property is null before calling the member function Equals(), potentially causing a NULL dereference.
Code Example:
Bad
Java
javaThe traditional defense of this coding error is: "I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or allow the program to die dereferencing a null value." But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved.
ID : DX-11
The following code shows a system property that is set to null and later dereferenced by a programmer who mistakenly assumes it will always be defined.Code Example:
Bad
Java
javaThe traditional defense of this coding error is: "I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or allow the program to die dereferencing a null value." But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved.
ID : DX-12
The following VB.NET code does not check to make sure that it has read 50 bytes from myfile.txt. This can cause DoDangerousOperation() to operate on an unexpected value.Code Example:
Bad
C#
c#In .NET, it is not uncommon for programmers to misunderstand Read() and related methods that are part of many System.IO classes. The stream and reader classes do not consider it to be unusual or exceptional if only a small amount of data becomes available. These classes simply add the small amount of data to the return buffer, and set the return value to the number of bytes or characters read. There is no guarantee that the amount of data returned is equal to the amount of data requested.
It is not uncommon for Java programmers to misunderstand read() and related methods that are part of many java.io classes. Most errors and unusual events in Java result in an exception being thrown. But the stream and reader classes do not consider it unusual or exceptional if only a small amount of data becomes available. These classes simply add the small amount of data to the return buffer, and set the return value to the number of bytes or characters read. There is no guarantee that the amount of data returned is equal to the amount of data requested. This behavior makes it important for programmers to examine the return value from read() and other IO methods to ensure that they receive the amount of data they expect.
ID : DX-1
This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer.Code Example:
Bad
C
c/*routine that ensures user_supplied_addr is in the right format for conversion /
cIf an attacker provides an address that appears to be well-formed, but the address does not resolve to a hostname, then the call to gethostbyaddr() will return NULL. Since the code does not check the return value from gethostbyaddr (Unchecked Return Value), a NULL pointer dereference (NULL Pointer Dereference) would then occur in the call to strcpy().
Note that this code is also vulnerable to a buffer overflow (Improper Restriction of Operations within the Bounds of a Memory Buffer).
ID : DX-24
The following function attempts to acquire a lock in order to perform operations on a shared resource.Code Example:
Bad
C
c/* access shared resource /
cHowever, the code does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program and result in undefined behavior.
In order to avoid data races, correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting them to higher levels.
Code Example:
Good
C
c/* access shared resource /
cObserved Examples 10
CVE-2020-17533Chain: unchecked return value (Unchecked Return Value) of some functions for policy enforcement leads to authorization bypass (Missing Authorization)
CVE-2020-6078Chain: The return value of a function returning a pointer is not checked for success (Unchecked Return Value) resulting in the later use of an uninitialized variable (Missing Initialization of a Variable) and a null pointer dereference (NULL Pointer Dereference)
CVE-2019-15900Chain: sscanf() call is used to check if a username and group exists, but the return value of sscanf() call is not checked (Unchecked Return Value), causing an uninitialized variable to be checked (Use of Uninitialized Variable), returning success to allow authorization bypass for executing a privileged (Incorrect Authorization).
CVE-2007-3798Unchecked return value leads to resultant integer overflow and code execution.
CVE-2006-4447Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.
CVE-2006-2916Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.
CVE-2008-5183chain: unchecked return value can lead to NULL dereference
CVE-2010-0211chain: unchecked return value (Unchecked Return Value) leads to free of invalid, uninitialized pointer (Access of Uninitialized Pointer).
CVE-2017-6964Linux-based device mapper encryption program does not check the return value of setuid and setgid allowing attackers to execute code with unintended privileges.
CVE-2002-1372Chain: Return values of file/socket operations are not checked (Unchecked Return Value), allowing resultant consumption of file descriptors (Missing Release of Resource after Effective Lifetime).
References 8
Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors
Katrina Tsipenyuk, Brian Chess, and Gary McGraw
NIST Workshop on Software Security Assurance Tools Techniques and Metrics • NIST
07-11-2005
ID: REF-6
The Art of Software Security Assessment
Mark Dowd, John McDonald, and Justin Schuh
Addison Wesley
2006
ID: REF-62
Writing Secure Code
Michael Howard and David LeBlanc
Microsoft Press
04-12-2002
ID: REF-7
24 Deadly Sins of Software Security
Michael Howard, David LeBlanc, and John Viega
McGraw-Hill
2010
ID: REF-44
Automated Source Code Reliability Measure (ASCRM)
Object Management Group (OMG)
01-2016
ID: REF-961
Automated Source Code Reliability Measure (ASCRM)
Object Management Group (OMG)
01-2016
ID: REF-961
Automated Source Code Security Measure (ASCSM)
Object Management Group (OMG)
01-2016
ID: REF-962
D3FEND: D3-NPC Null Pointer Checking
D3FEND
ID: REF-1484
Likelihood of Exploit
Low
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Modes of Introduction
Implementation
Related Weaknesses
Taxonomy Mapping
- 7 Pernicious Kingdoms
- CLASP
- OWASP Top Ten 2004
- CERT C Secure Coding
- CERT C Secure Coding
- The CERT Oracle Secure Coding Standard for Java (2011)
- SEI CERT Perl Coding Standard
- Software Fault Patterns
- OMG ASCSM
- OMG ASCRM
- OMG ASCRM