CWE-787: Out-of-bounds Write

Description:
The product writes data past the end, or before the beginning, of the intended buffer.

Affected languages: Memory-Unsafe, C, C++, Assembly
Affected technologies: ICS/OT
Parent weaknesses: CWE-119, CWE-119, CWE-119, CWE-119

Consequences:
  - Integrity: Modify Memory
  - Availability: DoS: Crash, Exit, or Restart
  - Other: Unexpected State

Detection methods:
  - Automated Static Analysis: This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives. 
         
  - Automated Dynamic Analysis: This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, a
  - Automated Dynamic Analysis: 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].

Mitigations:
  - [Requirements] Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. 
                   For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada
  - [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. 
                   Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. Thes
  - [Operation] 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 detectio
  - [Implementation] Consider adhering to the following rules when allocating and managing an application's memory: 
                      
                         Double check that the buffer is as large as specified. 
                         When using functions that accept a number of bytes to copy, such as strncpy

Demonstrative examples:
The following code attempts to save four different identification numbers into an array.
Since the array is only allocated to hold three elements, the valid indices are 0 to 2; so, the assignment to id_sequence[3] is out of bounds.
int id_sequence[3]; 
                      /* Populate the id array. */ 
                      id_sequence[0] = 123; id_sequence[1] = 234; id_sequence[2] = 345; id_sequence[3] = 456;

In the following code, it is possible to request that memcpy move a much larger segment of memory than assumed:
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).
int returnChunkSize(void *) { 
                         
                            
                            /* if chunk info is valid, return the size of usable memory, 
                            
                            
                           

Real-world examples:
  - CVE-2025-27363: Font rendering library does not properly
               handle assigning a signed short value to an unsigned
               long (CWE-195), leading to an integer wraparound
               (CWE-190), c
  - CVE-2023-1017: The reference implementation code for a Trusted Platform Module does not implement length checks on data, allowing for an attacker to write 2 bytes past the end of a buffer.
  - CVE-2021-21220: Chain: insufficient input validation (CWE-20) in browser allows heap corruption (CWE-787), as exploited in the wild per CISA KEV.
  - CVE-2021-28664: GPU kernel driver allows memory corruption because a user can obtain read/write access to read-only pages, as exploited in the wild per CISA KEV.
  - CVE-2020-17087: Chain: integer truncation (CWE-197) causes small buffer allocation (CWE-131) leading to out-of-bounds write (CWE-787) in kernel pool, as exploited in the wild per CISA KEV.