CWE-762: Mismatched Memory Management Routines

Description

The product attempts to return a memory resource to the system, but it calls a release function that is not compatible with the function that was originally used to allocate that resource.

This weakness can be generally described as mismatching memory management routines, such as: When the memory management functions are mismatched, the consequences may be as severe as code execution, memory corruption, or program crash. Consequences and ease of exploit will vary depending on the implementation of the routines and the object being managed.

Potential Impact

Integrity, Availability, Confidentiality

Modify Memory, DoS: Crash, Exit, or Restart, Execute Unauthorized Code or Commands

Demonstrative Examples

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.

Bad

void foo(){
                        BarObj *ptr = new BarObj()
                           /* do some work with ptr here */
                           
                           ...
                           free(ptr);
                     }

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.

Good

void foo(){
                        BarObj *ptr = new BarObj()
                           /* do some work with ptr here */
                           
                           ...
                           delete ptr;
                     }

In this example, the program does not use matching functions such as malloc/free, new/delete, and new[]/delete[] to allocate/deallocate the resource.

Bad

class A {void foo();};void A::foo(){int *ptr;ptr = (int*)malloc(sizeof(int));delete ptr;}

In this example, the program calls the delete[] function on non-heap memory.

Bad

class A{void foo(bool);};void A::foo(bool heap) {int localArray[2] = {11,22};int *p = localArray;if (heap){p = new int[2];}delete[] p;}

Mitigations & Prevention

Implementation

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

Implementation

Choose a language or tool that provides automatic memory management, or makes manual memory management less error-prone. For example, glibc in Linux provides protection against free of invalid pointers. When using Xcode to target OS X or iOS, enable automatic reference counting (ARC) [REF-391]. To help correctly and consistently manage memory when programming in C++, consider using a smart pointer class such as std::auto_ptr (defined by

Architecture and Design

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, glibc in Linux provides protection against free of invalid pointers.

Architecture and Design

Use a language that provides abstractions for memory allocation and deallocation.

Detection Methods

Automated Dynamic Analysis Moderate — Use tools that are integrated during compilation to insert runtime error-checking mechanisms related to memory safety errors, such as AddressSanitizer (ASan) for C/C++ [REF-1518] or valgrind [REF-480].

Taxonomy Mappings

CERT C Secure Coding: WIN30-C — Properly pair allocation and deallocation functions
Software Fault Patterns: SFP12 — Faulty Memory Release

Frequently Asked Questions

What is CWE-762?

CWE-762 (Mismatched Memory Management Routines) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Variant-level weakness. The product attempts to return a memory resource to the system, but it calls a release function that is not compatible with the function that was originally used to allocate that resource.

How can CWE-762 be exploited?

Attackers can exploit CWE-762 (Mismatched Memory Management Routines) to modify memory, dos: crash, exit, or restart, execute unauthorized code or commands. This weakness is typically introduced during the Implementation phase of software development.

How do I prevent CWE-762?

Key mitigations 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().

What is the severity of CWE-762?

CWE-762 is classified as a Variant-level weakness (Low-Medium abstraction). Its actual severity depends on the specific context and how the weakness manifests in your application.