CWE - CWE-252: Unchecked Return Value (4.16)

Weakness ID: 252

Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.

View customized information:

For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.

Description

The product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.

Extended Description

Two common programmer assumptions are "this function call can never fail" and "it doesn't matter if this function call fails". If an attacker can force the function to fail or otherwise return a value that is not expected, then the subsequent program logic could lead to a vulnerability, because the product is not in a state that the programmer assumes. For example, if the program calls a function to drop privileges but does not check the return code to ensure that privileges were successfully dropped, then the program will continue to operate with the higher privileges.

Common Consequences

This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

Scope	Impact	Likelihood
Availability Integrity	Technical Impact: Unexpected State; DoS: 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.

Potential Mitigations

Phase: Implementation

Check the results of all functions that return a value and verify that the value is expected.

Effectiveness: High

Note: Checking the return value of the function will typically be sufficient, however beware of race conditions (CWE-362) in a concurrent environment.

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.

Relationships

This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	754	Improper Check for Unusual or Exceptional Conditions
ParentOf	Chain - a Compound Element that is a sequence of two or more separate weaknesses that can be closely linked together within software. One weakness, X, can directly create the conditions that are necessary to cause another weakness, Y, to enter a vulnerable condition. When this happens, CWE refers to X as "primary" to Y, and Y is "resultant" from X. Chains can involve more than two weaknesses, and in some cases, they might have a tree-like structure.	690	Unchecked Return Value to NULL Pointer Dereference
PeerOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	273	Improper Check for Dropped Privileges
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	476	NULL Pointer Dereference

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	389	Error Conditions, Return Values, Status Codes

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	754	Improper Check for Unusual or Exceptional Conditions

Background Details

Many functions will return some value about the success of their actions. This will alert the program whether or not to handle any errors caused by that function.

Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

Phase	Note
Implementation

Applicable Platforms

This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Likelihood Of Exploit

Low

Demonstrative Examples

Example 1

Consider the following code segment:

(bad code)

Example Language: C

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 2

In the following example, it is possible to request that memcpy move a much larger segment of memory than assumed:

(bad code)

Example Language: C

int returnChunkSize(void *) {

/* if chunk info is valid, return the size of usable memory,

* else, return -1 to indicate an error

*/
...

}
int main() {

...
memcpy(destBuf, srcBuf, (returnChunkSize(destBuf)-1));
...

}

If returnChunkSize() happens to encounter an error it will return -1. Notice that the return value is not checked before the memcpy operation (CWE-252), so -1 can be passed as the size argument to memcpy() (CWE-805). Because memcpy() assumes that the value is unsigned, it will be interpreted as MAXINT-1 (CWE-195), and therefore will copy far more memory than is likely available to the destination buffer (CWE-787, CWE-788).

Example 3

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

(bad code)

Example Language: C

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 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.

Example 4

The following examples read a file into a byte array.

(bad code)

Example Language: C#

char[] byteArray = new char[1024];
for (IEnumerator i=users.GetEnumerator(); i.MoveNext() ;i.Current()) {

String userName = (String) i.Current();
String pFileName = PFILE_ROOT + "/" + userName;
StreamReader sr = new StreamReader(pFileName);
sr.Read(byteArray,0,1024);//the file is always 1k bytes
sr.Close();
processPFile(userName, byteArray);

}

(bad code)

Example Language: Java

FileInputStream fis;
byte[] byteArray = new byte[1024];
for (Iterator i=users.iterator(); i.hasNext();) {

String userName = (String) i.next();
String pFileName = PFILE_ROOT + "/" + userName;
FileInputStream fis = new FileInputStream(pFileName);
fis.read(byteArray); // the file is always 1k bytes
fis.close();
processPFile(userName, byteArray);

The 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.

Example 5

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.

(bad code)

Example Language: Java

String itemName = request.getParameter(ITEM_NAME);
if (itemName.compareTo(IMPORTANT_ITEM) == 0) {

...

}
...

The 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.

(bad code)

Example Language: Java

String itemName = request.Item(ITEM_NAME);
if (itemName.Equals(IMPORTANT_ITEM)) {

...

}
...

The 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.

Example 6

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.

(bad code)

Example Language: Java

System.clearProperty("os.name");
...
String os = System.getProperty("os.name");
if (os.equalsIgnoreCase("Windows 95")) System.out.println("Not supported");

Example 7

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.

(bad code)

Example Language: C#

Dim MyFile As New FileStream("myfile.txt", FileMode.Open, FileAccess.Read, FileShare.Read)
Dim MyArray(50) As Byte
MyFile.Read(MyArray, 0, 50)
DoDangerousOperation(MyArray(20))

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.

Example 8

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.

Example 9

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.

(bad code)

Example Language: C

void host_lookup(char *user_supplied_addr){

struct hostent *hp;
in_addr_t *addr;
char hostname[64];
in_addr_t inet_addr(const char *cp);

/*routine that ensures user_supplied_addr is in the right format for conversion */

validate_addr_form(user_supplied_addr);
addr = inet_addr(user_supplied_addr);
hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET);
strcpy(hostname, hp->h_name);

}

If 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 (CWE-252), a NULL pointer dereference (CWE-476) would then occur in the call to strcpy().

Note that this code is also vulnerable to a buffer overflow (CWE-119).

Example 10

The following function attempts to acquire a lock in order to perform operations on a shared resource.

(bad code)

Example Language: C

void f(pthread_mutex_t *mutex) {

pthread_mutex_lock(mutex);

/* access shared resource */

pthread_mutex_unlock(mutex);

}

However, 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.

(good code)

Example Language: C

int f(pthread_mutex_t *mutex) {

int result;

result = pthread_mutex_lock(mutex);
if (0 != result)

return result;

/* access shared resource */

return pthread_mutex_unlock(mutex);

}

Observed Examples

Reference	Description
CVE-2020-17533	Chain: unchecked return value (CWE-252) of some functions for policy enforcement leads to authorization bypass (CWE-862)
CVE-2020-6078	Chain: The return value of a function returning a pointer is not checked for success (CWE-252) resulting in the later use of an uninitialized variable (CWE-456) and a null pointer dereference (CWE-476)
CVE-2019-15900	Chain: sscanf() call is used to check if a username and group exists, but the return value of sscanf() call is not checked (CWE-252), causing an uninitialized variable to be checked (CWE-457), returning success to allow authorization bypass for executing a privileged (CWE-863).
CVE-2007-3798	Unchecked return value leads to resultant integer overflow and code execution.
CVE-2006-4447	Program 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-2916	Program 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-5183	chain: unchecked return value can lead to NULL dereference
CVE-2010-0211	chain: unchecked return value (CWE-252) leads to free of invalid, uninitialized pointer (CWE-824).
CVE-2017-6964	Linux-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-1372	Chain: Return values of file/socket operations are not checked (CWE-252), allowing resultant consumption of file descriptors (CWE-772).

Weakness Ordinalities

Ordinality	Description
Primary	(where the weakness exists independent of other weaknesses)

Detection Methods

Automated Static Analysis

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.)

Effectiveness: High

Memberships

This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	227	7PK - API Abuse
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	728	OWASP Top Ten 2004 Category A7 - Improper Error Handling
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	742	CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	847	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 4 - Expressions (EXP)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	876	CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	962	SFP Secondary Cluster: Unchecked Status Condition
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1129	CISQ Quality Measures (2016) - Reliability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1131	CISQ Quality Measures (2016) - Security
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1136	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 02. Expressions (EXP)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1167	SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1171	SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1181	SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1306	CISQ Quality Measures - Reliability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1308	CISQ Quality Measures - Security
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1405	Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
7 Pernicious Kingdoms			Unchecked Return Value
CLASP			Ignored function return value
OWASP Top Ten 2004	A7	CWE More Specific	Improper Error Handling
CERT C Secure Coding	ERR33-C	Imprecise	Detect and handle standard library errors
CERT C Secure Coding	POS54-C	Imprecise	Detect and handle POSIX library errors
The CERT Oracle Secure Coding Standard for Java (2011)	EXP00-J		Do not ignore values returned by methods
SEI CERT Perl Coding Standard	EXP32-PL	Exact	Do not ignore function return values
Software Fault Patterns	SFP4		Unchecked Status Condition
OMG ASCSM	ASCSM-CWE-252-resource
OMG ASCRM	ASCRM-CWE-252-data
OMG ASCRM	ASCRM-CWE-252-resource

References

[REF-6] Katrina Tsipenyuk, Brian Chess and Gary McGraw. "Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors". NIST Workshop on Software Security Assurance Tools Techniques and Metrics. NIST. 2005-11-07. <https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf>.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Program Building Blocks" Page 341. 1st Edition. Addison Wesley. 2006.

[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 20, "Checking Returns" Page 624. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.

[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 11: Failure to Handle Errors Correctly." Page 183. McGraw-Hill. 2010.

[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-CWE-252-data. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.

[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-CWE-252-resource. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.

[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-252-resource. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	7 Pernicious Kingdoms
2006-07-19 (CWE Draft 3, 2006-07-19)
Contributions
Contribution Date	Contributor	Organization
2010-04-30	Martin Sebor	Cisco Systems, Inc.
2010-04-30	Provided Demonstrative Example and suggested CERT reference
Modifications
Modification Date	Modifier	Organization
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Relationships, Taxonomy_Mappings
2009-01-12	CWE Content Team	MITRE
2009-01-12	updated Background_Details, Demonstrative_Examples, Description, Observed_Examples, Other_Notes, Potential_Mitigations
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Relationships
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Demonstrative_Examples
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Demonstrative_Examples
2009-12-28	CWE Content Team	MITRE
2009-12-28	updated Common_Consequences, Demonstrative_Examples, References
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Demonstrative_Examples, Potential_Mitigations, References
2010-04-05	CWE Content Team	MITRE
2010-04-05	updated Demonstrative_Examples
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Demonstrative_Examples, References
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Observed_Examples
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Demonstrative_Examples
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Demonstrative_Examples, Relationships, Taxonomy_Mappings
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Common_Consequences
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Common_Consequences, References, Relationships
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Demonstrative_Examples, Potential_Mitigations
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, References, Relationships, Taxonomy_Mappings
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated References
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated References, Relationships, Taxonomy_Mappings
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated References
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Observed_Examples
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Demonstrative_Examples, Observed_Examples, Relationships, Weakness_Ordinalities
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Observed_Examples
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes, Relationships
2023-10-26	CWE Content Team	MITRE
2023-10-26	updated Observed_Examples


	Site Map \| Terms of Use \| Manage Cookies \| Cookie Notice \| Privacy Policy \| Contact Us \| Use of the Common Weakness Enumeration (CWE™) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006–2024, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.

Common Weakness Enumeration

CWE-252: Unchecked Return Value

Edit Custom Filter