CWE-122: Heap-based Buffer Overflow

Description

A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc().

Potential Impact

Availability

DoS: Crash, Exit, or Restart, DoS: Resource Consumption (CPU), DoS: Resource Consumption (Memory)

Integrity, Confidentiality, Availability, Access Control

Execute Unauthorized Code or Commands, Bypass Protection Mechanism, Modify Memory

Integrity, Confidentiality, Availability, Access Control, Other

Execute Unauthorized Code or Commands, Bypass Protection Mechanism, Other

Demonstrative Examples

While buffer overflow examples can be rather complex, it is possible to have very simple, yet still exploitable, heap-based buffer overflows:

Bad

#define BUFSIZE 256int main(int argc, char **argv) {char *buf;buf = (char *)malloc(sizeof(char)*BUFSIZE);strcpy(buf, argv[1]);}

The buffer is allocated heap memory with a fixed size, but there is no guarantee the string in argv[1] will not exceed this size and cause an overflow.

This example applies an encoding procedure to an input string and stores it into a buffer.

Bad

char * copy_input(char *user_supplied_string){
                        int i, dst_index;char *dst_buf = (char*)malloc(4*sizeof(char) * MAX_SIZE);if ( MAX_SIZE <= strlen(user_supplied_string) ){die("user string too long, die evil hacker!");}dst_index = 0;for ( i = 0; i < strlen(user_supplied_string); i++ ){
                              if( '&' == user_supplied_string[i] ){dst_buf[dst_index++] = '&';dst_buf[dst_index++] = 'a';dst_buf[dst_index++] = 'm';dst_buf[dst_index++] = 'p';dst_buf[dst_index++] = ';';}else if ('<' == user_supplied_string[i] ){
                                    
                                       
                                       /* encode to &lt; */
                                       
                                    
                                 }else dst_buf[dst_index++] = user_supplied_string[i];
                           }return dst_buf;
                     }

The programmer attempts to encode the ampersand character in the user-controlled string, however the length of the string is validated before the encoding procedure is applied. Furthermore, the programmer assumes encoding expansion will only expand a given character by a factor of 4, while the encoding of the ampersand expands by 5. As a result, when the encoding procedure expands the string it is possible to overflow the destination buffer if the attacker provides a string of many ampersands.

Mitigations & Prevention

General

Pre-design: Use a language or compiler that performs automatic bounds checking.

Architecture and Design

Use an abstraction library to abstract away risky APIs. Not a complete solution.

OperationBuild and Compilation Defense in Depth

Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking. D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.

OperationBuild and Compilation Defense in Depth

Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code. Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other mo

Implementation

Implement and perform bounds checking on input.

Implementation

Do not use dangerous functions such as gets. Look for their safe equivalent, which checks for the boundary.

Operation

Use OS-level preventative functionality. This is not a complete solution, but it provides some defense in depth.

Detection Methods

Fuzzing High — Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption,
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].

Real-World CVE Examples

CVE ID	Description
CVE-2025-46687	Chain: Javascript engine code does not perform a length check (CWE-1284) leading to integer overflow (CWE-190) causing allocation of smaller buffer than expected (CWE-131) resulting in a heap-based bu
CVE-2021-43537	Chain: in a web browser, an unsigned 64-bit integer is forcibly cast to a 32-bit integer (CWE-681) and potentially leading to an integer overflow (CWE-190). If an integer overflow occurs, this can cau
CVE-2007-4268	Chain: integer signedness error (CWE-195) passes signed comparison, leading to heap overflow (CWE-122)
CVE-2009-2523	Chain: product does not handle when an input string is not NULL terminated (CWE-170), leading to buffer over-read (CWE-125) or heap-based buffer overflow (CWE-122).
CVE-2021-29529	Chain: machine-learning product can have a heap-based buffer overflow (CWE-122) when some integer-oriented bounds are calculated by using ceiling() and floor() on floating point values
CVE-2010-1866	Chain: integer overflow (CWE-190) causes a negative signed value, which later bypasses a maximum-only check (CWE-839), leading to heap-based buffer overflow (CWE-122).

Taxonomy Mappings

CLASP: — Heap overflow
Software Fault Patterns: SFP8 — Faulty Buffer Access
CERT C Secure Coding: STR31-C — Guarantee that storage for strings has sufficient space for character data and the null terminator
ISA/IEC 62443: Part 4-2 — Req CR 3.5
ISA/IEC 62443: Part 3-3 — Req SR 3.5
ISA/IEC 62443: Part 4-1 — Req SI-1
ISA/IEC 62443: Part 4-1 — Req SI-2
ISA/IEC 62443: Part 4-1 — Req SVV-1
ISA/IEC 62443: Part 4-1 — Req SVV-3

Frequently Asked Questions

What is CWE-122?

CWE-122 (Heap-based Buffer Overflow) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Variant-level weakness. A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine suc...

How can CWE-122 be exploited?

Attackers can exploit CWE-122 (Heap-based Buffer Overflow) to dos: crash, exit, or restart, dos: resource consumption (cpu), dos: resource consumption (memory). This weakness is typically introduced during the Implementation phase of software development.

How do I prevent CWE-122?

Key mitigations include: Pre-design: Use a language or compiler that performs automatic bounds checking.

What is the severity of CWE-122?

CWE-122 is classified as a Variant-level weakness (Low-Medium abstraction). It has been observed in 6 real-world CVEs.