The product attempts to return a memory resource to the system, but it calls the wrong release function or calls the appropriate release function incorrectly.
View on MITREThis weakness can take several forms, such as: The memory was allocated, explicitly or implicitly, via one memory management method and deallocated using a different, non-compatible function (CWE-762). The function calls or memory management routines chosen are appropriate, however they are used incorrectly, such as in CWE-761.
This weakness may result in the corruption of memory, and perhaps instructions, possibly leading to a crash. If the corrupted memory can be effectively controlled, it may be possible to execute arbitrary code.
Only call matching memory management functions. Do not mix and match routines. For example, when you allocate a buffer with malloc(), dispose of the original pointer with free().
When programming in C++, consider using smart pointers provided by the boost library to help correctly and consistently manage memory.
Use a language that provides abstractions for memory allocation and deallocation.
Use a tool that dynamically detects memory management problems, such as valgrind.
No detection method information available for this CWE.
This code attempts to tokenize a string and place it into an array using the strsep function, which inserts a \0 byte in place of whitespace or a tab character. After finishing the loop, each string in the AP array points to a location within the input string.
Since strsep is not allocating any new memory, freeing an element in the middle of the array is equivalent to free a pointer in the middle of inputstring.
This example allocates a BarObj object using the new operator in C++, however, the programmer then deallocates the object using free(), which may lead to unexpected behavior.
Instead, the programmer should have either created the object with one of the malloc family functions, or else deleted the object with the delete operator.
This example allocates a BarObj object using the new operator in C++, however, the programmer then deallocates the object using free(), which may lead to unexpected behavior.
Instead, the programmer should have either created the object with one of the malloc family functions, or else deleted the object with the delete operator.
In this example, the programmer dynamically allocates a buffer to hold a string and then searches for a specific character. After completing the search, the programmer attempts to release the allocated memory and return SUCCESS or FAILURE to the caller. Note: for simplification, this example uses a hard-coded "Search Me!" string and a constant string length of 20.
However, if the character is not at the beginning of the string, or if it is not in the string at all, then the pointer will not be at the start of the buffer when the programmer frees it.
In this example, the programmer dynamically allocates a buffer to hold a string and then searches for a specific character. After completing the search, the programmer attempts to release the allocated memory and return SUCCESS or FAILURE to the caller. Note: for simplification, this example uses a hard-coded "Search Me!" string and a constant string length of 20.
However, if the character is not at the beginning of the string, or if it is not in the string at all, then the pointer will not be at the start of the buffer when the programmer frees it.
Consider the following code in the context of a parsing application to extract commands out of user data. The intent is to parse each command and add it to a queue of commands to be executed, discarding each malformed entry.
While the above code attempts to free memory associated with bad commands, since the memory was all allocated in one chunk, it must all be freed together.
Consider the following code in the context of a parsing application to extract commands out of user data. The intent is to parse each command and add it to a queue of commands to be executed, discarding each malformed entry.
While the above code attempts to free memory associated with bad commands, since the memory was all allocated in one chunk, it must all be freed together.
function "internally calls 'calloc' and returns a pointer at an index... inside the allocated buffer. This led to freeing invalid memory."
View DetailsCWE-763: Release of Invalid Pointer or Reference is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product attempts to return a memory resource to the system, but it calls the wrong release function or calls the appropriate release function incorrectly. This weakness can take several forms, such as: The memory was allocated, explicitly or implicitly, via one memory management method and deallocated using a different, non-compatible function (CWE-762). The function calls or memory management routines chosen are appropriate, however they are used incorrectly, such as in CWE-761.
If exploited, CWE-763 (Release of Invalid Pointer or Reference) it can compromise Integrity, Availability and Confidentiality, leading to outcomes such as Modify Memory, DoS: Crash, Exit, or Restart and Execute Unauthorized Code or Commands.
Recommended mitigations for CWE-763 include: Only call matching memory management functions. Do not mix and match routines. For example, when you allocate a buffer with malloc(), dispose of the original pointer with free(). When programming in C++, consider using smart pointers provided by the boost library to help correctly and consistently manage memory. Use a language that provides abstractions for memory allocation and deallocation.
CWE-763 commonly affects C and C++. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.
MITRE documents real CVEs mapped to CWE-763, including CVE-2019-11930. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.
A CWE (Common Weakness Enumeration) like CWE-763 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.