Home > CWE List > VIEW SLICE: CWE-1154: Weaknesses Addressed by the SEI CERT C Coding Standard (4.16) |
|
CWE VIEW: Weaknesses Addressed by the SEI CERT C Coding Standard
CWE entries in this view (graph) are fully or partially eliminated by following the guidance presented in the online wiki that reflects that current rules and recommendations of the SEI CERT C Coding Standard.
The following graph shows the tree-like relationships between
weaknesses that exist at different levels of abstraction. At the highest level, categories
and pillars exist to group weaknesses. Categories (which are not technically weaknesses) are
special CWE entries used to group weaknesses that share a common characteristic. Pillars are
weaknesses that are described in the most abstract fashion. Below these top-level entries
are weaknesses are varying levels of abstraction. Classes are still very abstract, typically
independent of any specific language or technology. Base level weaknesses are used to
present a more specific type of weakness. A variant is a weakness that is described at a
very low level of detail, typically limited to a specific language or technology. A chain is
a set of weaknesses that must be reachable consecutively in order to produce an exploitable
vulnerability. While a composite is a set of weaknesses that must all be present
simultaneously in order to produce an exploitable vulnerability.
Show Details:
1154 - Weaknesses Addressed by the SEI CERT C Coding Standard
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1155
(SEI CERT C Coding Standard - Guidelines 01. Preprocessor (PRE))
Weaknesses in this category are related to the rules and recommendations in the Preprocessor (PRE) section of the SEI CERT C Coding Standard.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1156
(SEI CERT C Coding Standard - Guidelines 02. Declarations and Initialization (DCL))
Weaknesses in this category are related to the rules and recommendations in the Declarations and Initialization (DCL) section of the SEI CERT C Coding Standard.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1156
(SEI CERT C Coding Standard - Guidelines 02. Declarations and Initialization (DCL)) >
562
(Return of Stack Variable Address)
A function returns the address of a stack variable, which will cause unintended program behavior, typically in the form of a crash.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP))
Weaknesses in this category are related to the rules and recommendations in the Expressions (EXP) section of the SEI CERT C Coding Standard.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
758
(Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)
The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
908
(Use of Uninitialized Resource)
The product uses or accesses a resource that has not been initialized.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
476
(NULL Pointer Dereference)
The product dereferences a pointer that it expects to be valid but is NULL.
NPD
null deref
NPE
nil pointer dereference
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
690
(Unchecked Return Value to NULL Pointer Dereference)
The product does not check for an error after calling a function that can return with a NULL pointer if the function fails, which leads to a resultant NULL pointer dereference.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
628
(Function Call with Incorrectly Specified Arguments)
The product calls a function, procedure, or routine with arguments that are not correctly specified, leading to always-incorrect behavior and resultant weaknesses.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
685
(Function Call With Incorrect Number of Arguments)
The product calls a function, procedure, or routine, but the caller specifies too many arguments, or too few arguments, which may lead to undefined behavior and resultant weaknesses.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
686
(Function Call With Incorrect Argument Type)
The product calls a function, procedure, or routine, but the caller specifies an argument that is the wrong data type, which may lead to resultant weaknesses.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
843
(Access of Resource Using Incompatible Type ('Type Confusion'))
The product allocates or initializes a resource such as a pointer, object, or variable using one type, but it later accesses that resource using a type that is incompatible with the original type.
Object Type Confusion
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
704
(Incorrect Type Conversion or Cast)
The product does not correctly convert an object, resource, or structure from one type to a different type.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer)
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Buffer Overflow
buffer overrun
memory safety
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
125
(Out-of-bounds Read)
The product reads data past the end, or before the beginning, of the intended buffer.
OOB read
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
480
(Use of Incorrect Operator)
The product accidentally uses the wrong operator, which changes the logic in security-relevant ways.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1157
(SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)) >
481
(Assigning instead of Comparing)
The code uses an operator for assignment when the intention was to perform a comparison.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT))
Weaknesses in this category are related to the rules and recommendations in the Integers (INT) section of the SEI CERT C Coding Standard.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
190
(Integer Overflow or Wraparound)
The product performs a calculation that can
produce an integer overflow or wraparound when the logic
assumes that the resulting value will always be larger than
the original value. This occurs when an integer value is
incremented to a value that is too large to store in the
associated representation. When this occurs, the value may
become a very small or negative number.
Overflow
Wraparound
wrap, wrap-around, wrap around
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
131
(Incorrect Calculation of Buffer Size)
The product does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
191
(Integer Underflow (Wrap or Wraparound))
The product subtracts one value from another, such that the result is less than the minimum allowable integer value, which produces a value that is not equal to the correct result.
Integer underflow
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
680
(Integer Overflow to Buffer Overflow)
The product performs a calculation to determine how much memory to allocate, but an integer overflow can occur that causes less memory to be allocated than expected, leading to a buffer overflow.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
192
(Integer Coercion Error)
Integer coercion refers to a set of flaws pertaining to the type casting, extension, or truncation of primitive data types.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
197
(Numeric Truncation Error)
Truncation errors occur when a primitive is cast to a primitive of a smaller size and data is lost in the conversion.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
681
(Incorrect Conversion between Numeric Types)
When converting from one data type to another, such as long to integer, data can be omitted or translated in a way that produces unexpected values. If the resulting values are used in a sensitive context, then dangerous behaviors may occur.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
704
(Incorrect Type Conversion or Cast)
The product does not correctly convert an object, resource, or structure from one type to a different type.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
194
(Unexpected Sign Extension)
The product performs an operation on a number that causes it to be sign extended when it is transformed into a larger data type. When the original number is negative, this can produce unexpected values that lead to resultant weaknesses.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
195
(Signed to Unsigned Conversion Error)
The product uses a signed primitive and performs a cast to an unsigned primitive, which can produce an unexpected value if the value of the signed primitive can not be represented using an unsigned primitive.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
369
(Divide By Zero)
The product divides a value by zero.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
682
(Incorrect Calculation)
The product performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
758
(Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)
The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1158
(SEI CERT C Coding Standard - Guidelines 04. Integers (INT)) >
587
(Assignment of a Fixed Address to a Pointer)
The product sets a pointer to a specific address other than NULL or 0.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1159
(SEI CERT C Coding Standard - Guidelines 05. Floating Point (FLP))
Weaknesses in this category are related to the rules and recommendations in the Floating Point (FLP) section of the SEI CERT C Coding Standard.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1159
(SEI CERT C Coding Standard - Guidelines 05. Floating Point (FLP)) >
682
(Incorrect Calculation)
The product performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1159
(SEI CERT C Coding Standard - Guidelines 05. Floating Point (FLP)) >
391
(Unchecked Error Condition)
[PLANNED FOR DEPRECATION. SEE MAINTENANCE NOTES AND CONSIDER CWE-252, CWE-248, OR CWE-1069.] Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1159
(SEI CERT C Coding Standard - Guidelines 05. Floating Point (FLP)) >
681
(Incorrect Conversion between Numeric Types)
When converting from one data type to another, such as long to integer, data can be omitted or translated in a way that produces unexpected values. If the resulting values are used in a sensitive context, then dangerous behaviors may occur.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1159
(SEI CERT C Coding Standard - Guidelines 05. Floating Point (FLP)) >
197
(Numeric Truncation Error)
Truncation errors occur when a primitive is cast to a primitive of a smaller size and data is lost in the conversion.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR))
Weaknesses in this category are related to the rules and recommendations in the Arrays (ARR) section of the SEI CERT C Coding Standard.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer)
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Buffer Overflow
buffer overrun
memory safety
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) >
129
(Improper Validation of Array Index)
The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.
out-of-bounds array index
index-out-of-range
array index underflow
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) >
786
(Access of Memory Location Before Start of Buffer)
The product reads or writes to a buffer using an index or pointer that references a memory location prior to the beginning of the buffer.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) >
123
(Write-what-where Condition)
Any condition where the attacker has the ability to write an arbitrary value to an arbitrary location, often as the result of a buffer overflow.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) >
125
(Out-of-bounds Read)
The product reads data past the end, or before the beginning, of the intended buffer.
OOB read
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) >
758
(Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)
The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) >
469
(Use of Pointer Subtraction to Determine Size)
The product subtracts one pointer from another in order to determine size, but this calculation can be incorrect if the pointers do not exist in the same memory chunk.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) >
121
(Stack-based Buffer Overflow)
A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).
Stack Overflow
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) >
805
(Buffer Access with Incorrect Length Value)
The product uses a sequential operation to read or write a buffer, but it uses an incorrect length value that causes it to access memory that is outside of the bounds of the buffer.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1160
(SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)) >
468
(Incorrect Pointer Scaling)
In C and C++, one may often accidentally refer to the wrong memory due to the semantics of when math operations are implicitly scaled.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1161
(SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR))
Weaknesses in this category are related to the rules and recommendations in the Characters and Strings (STR) section of the SEI CERT C Coding Standard.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1161
(SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) >
120
(Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'))
The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.
Classic Buffer Overflow
Unbounded Transfer
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1161
(SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer)
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Buffer Overflow
buffer overrun
memory safety
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1161
(SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) >
121
(Stack-based Buffer Overflow)
A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).
Stack Overflow
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1161
(SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) >
122
(Heap-based Buffer Overflow)
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().
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1161
(SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) >
123
(Write-what-where Condition)
Any condition where the attacker has the ability to write an arbitrary value to an arbitrary location, often as the result of a buffer overflow.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1161
(SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) >
125
(Out-of-bounds Read)
The product reads data past the end, or before the beginning, of the intended buffer.
OOB read
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1161
(SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) >
676
(Use of Potentially Dangerous Function)
The product invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1161
(SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) >
170
(Improper Null Termination)
The product does not terminate or incorrectly terminates a string or array with a null character or equivalent terminator.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1161
(SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)) >
704
(Incorrect Type Conversion or Cast)
The product does not correctly convert an object, resource, or structure from one type to a different type.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM))
Weaknesses in this category are related to the rules and recommendations in the Memory Management (MEM) section of the SEI CERT C Coding Standard.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
416
(Use After Free)
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
Dangling pointer
UAF
Use-After-Free
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
672
(Operation on a Resource after Expiration or Release)
The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
758
(Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)
The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
666
(Operation on Resource in Wrong Phase of Lifetime)
The product performs an operation on a resource at the wrong phase of the resource's lifecycle, which can lead to unexpected behaviors.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
415
(Double Free)
The product calls free() twice on the same memory address, potentially leading to modification of unexpected memory locations.
Double-free
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
401
(Missing Release of Memory after Effective Lifetime)
The product does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory.
Memory Leak
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
404
(Improper Resource Shutdown or Release)
The product does not release or incorrectly releases a resource before it is made available for re-use.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
459
(Incomplete Cleanup)
The product does not properly "clean up" and remove temporary or supporting resources after they have been used.
Insufficient Cleanup
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
771
(Missing Reference to Active Allocated Resource)
The product does not properly maintain a reference to a resource that has been allocated, which prevents the resource from being reclaimed.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
772
(Missing Release of Resource after Effective Lifetime)
The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
590
(Free of Memory not on the Heap)
The product calls free() on a pointer to memory that was not allocated using associated heap allocation functions such as malloc(), calloc(), or realloc().
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
131
(Incorrect Calculation of Buffer Size)
The product does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
680
(Integer Overflow to Buffer Overflow)
The product performs a calculation to determine how much memory to allocate, but an integer overflow can occur that causes less memory to be allocated than expected, leading to a buffer overflow.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
467
(Use of sizeof() on a Pointer Type)
The code calls sizeof() on a pointer type, which can be an incorrect calculation if the programmer intended to determine the size of the data that is being pointed to.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
789
(Memory Allocation with Excessive Size Value)
The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.
Stack Exhaustion
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1162
(SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)) >
190
(Integer Overflow or Wraparound)
The product performs a calculation that can
produce an integer overflow or wraparound when the logic
assumes that the resulting value will always be larger than
the original value. This occurs when an integer value is
incremented to a value that is too large to store in the
associated representation. When this occurs, the value may
become a very small or negative number.
Overflow
Wraparound
wrap, wrap-around, wrap around
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO))
Weaknesses in this category are related to the rules and recommendations in the Input Output (FIO) section of the SEI CERT C Coding Standard.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
134
(Use of Externally-Controlled Format String)
The product uses a function that accepts a format string as an argument, but the format string originates from an external source.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
20
(Improper Input Validation)
The product receives input or data, but it does
not validate or incorrectly validates that the input has the
properties that are required to process the data safely and
correctly.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
67
(Improper Handling of Windows Device Names)
The product constructs pathnames from user input, but it does not handle or incorrectly handles a pathname containing a Windows device name such as AUX or CON. This typically leads to denial of service or an information exposure when the application attempts to process the pathname as a regular file.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
197
(Numeric Truncation Error)
Truncation errors occur when a primitive is cast to a primitive of a smaller size and data is lost in the conversion.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
241
(Improper Handling of Unexpected Data Type)
The product does not handle or incorrectly handles when a particular element is not the expected type, e.g. it expects a digit (0-9) but is provided with a letter (A-Z).
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
664
(Improper Control of a Resource Through its Lifetime)
The product does not maintain or incorrectly maintains control over a resource throughout its lifetime of creation, use, and release.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
404
(Improper Resource Shutdown or Release)
The product does not release or incorrectly releases a resource before it is made available for re-use.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
459
(Incomplete Cleanup)
The product does not properly "clean up" and remove temporary or supporting resources after they have been used.
Insufficient Cleanup
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
772
(Missing Release of Resource after Effective Lifetime)
The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
773
(Missing Reference to Active File Descriptor or Handle)
The product does not properly maintain references to a file descriptor or handle, which prevents that file descriptor/handle from being reclaimed.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
775
(Missing Release of File Descriptor or Handle after Effective Lifetime)
The product does not release a file descriptor or handle after its effective lifetime has ended, i.e., after the file descriptor/handle is no longer needed.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
771
(Missing Reference to Active Allocated Resource)
The product does not properly maintain a reference to a resource that has been allocated, which prevents the resource from being reclaimed.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
910
(Use of Expired File Descriptor)
The product uses or accesses a file descriptor after it has been closed.
Stale file descriptor
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
666
(Operation on Resource in Wrong Phase of Lifetime)
The product performs an operation on a resource at the wrong phase of the resource's lifecycle, which can lead to unexpected behaviors.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
672
(Operation on a Resource after Expiration or Release)
The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
758
(Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)
The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
686
(Function Call With Incorrect Argument Type)
The product calls a function, procedure, or routine, but the caller specifies an argument that is the wrong data type, which may lead to resultant weaknesses.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1163
(SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)) >
685
(Function Call With Incorrect Number of Arguments)
The product calls a function, procedure, or routine, but the caller specifies too many arguments, or too few arguments, which may lead to undefined behavior and resultant weaknesses.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1165
(SEI CERT C Coding Standard - Guidelines 10. Environment (ENV))
Weaknesses in this category are related to the rules and recommendations in the Environment (ENV) section of the SEI CERT C Coding Standard.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1165
(SEI CERT C Coding Standard - Guidelines 10. Environment (ENV)) >
705
(Incorrect Control Flow Scoping)
The product does not properly return control flow to the proper location after it has completed a task or detected an unusual condition.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1165
(SEI CERT C Coding Standard - Guidelines 10. Environment (ENV)) >
676
(Use of Potentially Dangerous Function)
The product invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1165
(SEI CERT C Coding Standard - Guidelines 10. Environment (ENV)) >
78
(Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'))
The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.
Shell injection
Shell metacharacters
OS Command Injection
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1165
(SEI CERT C Coding Standard - Guidelines 10. Environment (ENV)) >
88
(Improper Neutralization of Argument Delimiters in a Command ('Argument Injection'))
The product constructs a string for a command to be executed by a separate component
in another control sphere, but it does not properly delimit the
intended arguments, options, or switches within that command string.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1166
(SEI CERT C Coding Standard - Guidelines 11. Signals (SIG))
Weaknesses in this category are related to the rules and recommendations in the Signals (SIG) section of the SEI CERT C Coding Standard.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1166
(SEI CERT C Coding Standard - Guidelines 11. Signals (SIG)) >
479
(Signal Handler Use of a Non-reentrant Function)
The product defines a signal handler that calls a non-reentrant function.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1166
(SEI CERT C Coding Standard - Guidelines 11. Signals (SIG)) >
662
(Improper Synchronization)
The product utilizes multiple threads or processes to allow temporary access to a shared resource that can only be exclusive to one process at a time, but it does not properly synchronize these actions, which might cause simultaneous accesses of this resource by multiple threads or processes.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1167
(SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR))
Weaknesses in this category are related to the rules and recommendations in the Error Handling (ERR) section of the SEI CERT C Coding Standard.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1167
(SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)) >
456
(Missing Initialization of a Variable)
The product does not initialize critical variables, which causes the execution environment to use unexpected values.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1167
(SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)) >
391
(Unchecked Error Condition)
[PLANNED FOR DEPRECATION. SEE MAINTENANCE NOTES AND CONSIDER CWE-252, CWE-248, OR CWE-1069.] Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1167
(SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)) >
252
(Unchecked Return Value)
The product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1167
(SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)) >
253
(Incorrect Check of Function Return Value)
The product incorrectly checks a return value from a function, which prevents it from detecting errors or exceptional conditions.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1167
(SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)) >
676
(Use of Potentially Dangerous Function)
The product invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1167
(SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)) >
758
(Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)
The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1168
(SEI CERT C Coding Standard - Guidelines 13. Application Programming Interfaces (API))
Weaknesses in this category are related to the rules and recommendations in the Application Programming Interfaces (API) section of the SEI CERT C Coding Standard.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1169
(SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON))
Weaknesses in this category are related to the rules and recommendations in the Concurrency (CON) section of the SEI CERT C Coding Standard.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1169
(SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON)) >
667
(Improper Locking)
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1169
(SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON)) >
366
(Race Condition within a Thread)
If two threads of execution use a resource simultaneously, there exists the possibility that resources may be used while invalid, in turn making the state of execution undefined.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1169
(SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON)) >
676
(Use of Potentially Dangerous Function)
The product invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1169
(SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON)) >
330
(Use of Insufficiently Random Values)
The product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1169
(SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON)) >
377
(Insecure Temporary File)
Creating and using insecure temporary files can leave application and system data vulnerable to attack.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1170
(SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC))
Weaknesses in this category are related to the rules and recommendations in the Miscellaneous (MSC) section of the SEI CERT C Coding Standard.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1170
(SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)) >
327
(Use of a Broken or Risky Cryptographic Algorithm)
The product uses a broken or risky cryptographic algorithm or protocol.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1170
(SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)) >
330
(Use of Insufficiently Random Values)
The product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1170
(SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)) >
338
(Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG))
The product uses a Pseudo-Random Number Generator (PRNG) in a security context, but the PRNG's algorithm is not cryptographically strong.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1170
(SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)) >
676
(Use of Potentially Dangerous Function)
The product invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1170
(SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)) >
331
(Insufficient Entropy)
The product uses an algorithm or scheme that produces insufficient entropy, leaving patterns or clusters of values that are more likely to occur than others.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1170
(SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)) >
758
(Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)
The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1171
(SEI CERT C Coding Standard - Guidelines 50. POSIX (POS))
Weaknesses in this category are related to the rules and recommendations in the POSIX (POS) section of the SEI CERT C Coding Standard.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1171
(SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) >
170
(Improper Null Termination)
The product does not terminate or incorrectly terminates a string or array with a null character or equivalent terminator.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1171
(SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) >
242
(Use of Inherently Dangerous Function)
The product calls a function that can never be guaranteed to work safely.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1171
(SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) >
363
(Race Condition Enabling Link Following)
The product checks the status of a file or directory before accessing it, which produces a race condition in which the file can be replaced with a link before the access is performed, causing the product to access the wrong file.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1171
(SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) >
696
(Incorrect Behavior Order)
The product performs multiple related behaviors, but the behaviors are performed in the wrong order in ways which may produce resultant weaknesses.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1171
(SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) >
273
(Improper Check for Dropped Privileges)
The product attempts to drop privileges but does not check or incorrectly checks to see if the drop succeeded.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1171
(SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) >
667
(Improper Locking)
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1171
(SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) >
391
(Unchecked Error Condition)
[PLANNED FOR DEPRECATION. SEE MAINTENANCE NOTES AND CONSIDER CWE-252, CWE-248, OR CWE-1069.] Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1171
(SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) >
252
(Unchecked Return Value)
The product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1171
(SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)) >
253
(Incorrect Check of Function Return Value)
The product incorrectly checks a return value from a function, which prevents it from detecting errors or exceptional conditions.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1172
(SEI CERT C Coding Standard - Guidelines 51. Microsoft Windows (WIN) )
Weaknesses in this category are related to the rules and recommendations in the Microsoft Windows (WIN) section of the SEI CERT C Coding Standard.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1172
(SEI CERT C Coding Standard - Guidelines 51. Microsoft Windows (WIN) ) >
762
(Mismatched Memory Management Routines)
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.
![]() ![]()
1154
(Weaknesses Addressed by the SEI CERT C Coding Standard) >
1172
(SEI CERT C Coding Standard - Guidelines 51. Microsoft Windows (WIN) ) >
590
(Free of Memory not on the Heap)
The product calls free() on a pointer to memory that was not allocated using associated heap allocation functions such as malloc(), calloc(), or realloc().
Relationship
The relationships in this view were determined based on specific statements within the rules from the standard. Not all rules have direct relationships to individual weaknesses, although they likely have chaining relationships in specific circumstances.
View ComponentsA | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z
CWE-786: Access of Memory Location Before Start of Buffer
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.
×
Edit Custom FilterThe product reads or writes to a buffer using an index or pointer that references a memory location prior to the beginning of the buffer.
This typically occurs when a pointer or its index is decremented to a position before the buffer, when pointer arithmetic results in a position before the beginning of the valid memory location, or when a negative index is used.
![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]() ![]()
Example 1 In the following C/C++ example, a utility function is used to trim trailing whitespace from a character string. The function copies the input string to a local character string and uses a while statement to remove the trailing whitespace by moving backward through the string and overwriting whitespace with a NUL character. (bad code)
Example Language: C
char* trimTrailingWhitespace(char *strMessage, int length) {
char *retMessage;
char *message = malloc(sizeof(char)*(length+1)); // copy input string to a temporary string char message[length+1]; int index; for (index = 0; index < length; index++) { message[index] = strMessage[index]; }message[index] = '\0'; // trim trailing whitespace int len = index-1; while (isspace(message[len])) { message[len] = '\0'; }len--; // return string without trailing whitespace retMessage = message; return retMessage; However, this function can cause a buffer underwrite if the input character string contains all whitespace. On some systems the while statement will move backwards past the beginning of a character string and will call the isspace() function on an address outside of the bounds of the local buffer. Example 2 The following example asks a user for an offset into an array to select an item. (bad code)
Example Language: C
int main (int argc, char **argv) { char *items[] = {"boat", "car", "truck", "train"}; }int index = GetUntrustedOffset(); printf("You selected %s\n", items[index-1]); The programmer allows the user to specify which element in the list to select, however an attacker can provide an out-of-bounds offset, resulting in a buffer over-read (CWE-126). Example 3 The following is an example of code that may result in a buffer underwrite. This code is attempting to replace the substring "Replace Me" in destBuf with the string stored in srcBuf. It does so by using the function strstr(), which returns a pointer to the found substring in destBuf. Using pointer arithmetic, the starting index of the substring is found. (bad code)
Example Language: C
int main() {
... }
char *result = strstr(destBuf, "Replace Me"); int idx = result - destBuf; strcpy(&destBuf[idx], srcBuf); ... In the case where the substring is not found in destBuf, strstr() will return NULL, causing the pointer arithmetic to be undefined, potentially setting the value of idx to a negative number. If idx is negative, this will result in a buffer underwrite of destBuf.
![]()
CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
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.
×
Edit Custom FilterThe product allocates or initializes a resource such as a pointer, object, or variable using one type, but it later accesses that resource using a type that is incompatible with the original type.
When the product accesses the resource using an incompatible type, this could trigger logical errors because the resource does not have expected properties. In languages without memory safety, such as C and C++, type confusion can lead to out-of-bounds memory access. While this weakness is frequently associated with unions when parsing data with many different embedded object types in C, it can be present in any application that can interpret the same variable or memory location in multiple ways. This weakness is not unique to C and C++. For example, errors in PHP applications can be triggered by providing array parameters when scalars are expected, or vice versa. Languages such as Perl, which perform automatic conversion of a variable of one type when it is accessed as if it were another type, can also contain these issues. ![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]()
![]() Languages C (Undetermined Prevalence) C++ (Undetermined Prevalence) Example 1 The following code uses a union to support the representation of different types of messages. It formats messages differently, depending on their type. (bad code)
Example Language: C
#define NAME_TYPE 1
#define ID_TYPE 2 struct MessageBuffer { int msgType; };union { char *name; };int nameID; int main (int argc, char **argv) { struct MessageBuffer buf;
char *defaultMessage = "Hello World"; buf.msgType = NAME_TYPE; buf.name = defaultMessage; printf("Pointer of buf.name is %p\n", buf.name); /* This particular value for nameID is used to make the code architecture-independent. If coming from untrusted input, it could be any value. */ buf.nameID = (int)(defaultMessage + 1); printf("Pointer of buf.name is now %p\n", buf.name); if (buf.msgType == NAME_TYPE) { printf("Message: %s\n", buf.name); }else { printf("Message: Use ID %d\n", buf.nameID); }The code intends to process the message as a NAME_TYPE, and sets the default message to "Hello World." However, since both buf.name and buf.nameID are part of the same union, they can act as aliases for the same memory location, depending on memory layout after compilation. As a result, modification of buf.nameID - an int - can effectively modify the pointer that is stored in buf.name - a string. Execution of the program might generate output such as:
Pointer of name is 10830
Pointer of name is now 10831
Message: ello World
Notice how the pointer for buf.name was changed, even though buf.name was not explicitly modified. In this case, the first "H" character of the message is omitted. However, if an attacker is able to fully control the value of buf.nameID, then buf.name could contain an arbitrary pointer, leading to out-of-bounds reads or writes. Example 2 The following PHP code accepts a value, adds 5, and prints the sum. (bad code)
Example Language: PHP
$value = $_GET['value'];
$sum = $value + 5; echo "value parameter is '$value'<p>"; echo "SUM is $sum"; When called with the following query string:
value=123
the program calculates the sum and prints out:
SUM is 128
However, the attacker could supply a query string such as:
value[]=123
The "[]" array syntax causes $value to be treated as an array type, which then generates a fatal error when calculating $sum:
Fatal error: Unsupported operand types in program.php on line 2
Example 3 The following Perl code is intended to look up the privileges for user ID's between 0 and 3, by performing an access of the $UserPrivilegeArray reference. It is expected that only userID 3 is an admin (since this is listed in the third element of the array). (bad code)
Example Language: Perl
my $UserPrivilegeArray = ["user", "user", "admin", "user"];
my $userID = get_current_user_ID(); if ($UserPrivilegeArray eq "user") { print "Regular user!\n"; }else { print "Admin!\n"; }print "\$UserPrivilegeArray = $UserPrivilegeArray\n"; In this case, the programmer intended to use "$UserPrivilegeArray->{$userID}" to access the proper position in the array. But because the subscript was omitted, the "user" string was compared to the scalar representation of the $UserPrivilegeArray reference, which might be of the form "ARRAY(0x229e8)" or similar. Since the logic also "fails open" (CWE-636), the result of this bug is that all users are assigned administrator privileges. While this is a forced example, it demonstrates how type confusion can have security consequences, even in memory-safe languages.
![]()
Applicable Platform This weakness is possible in any type-unsafe programming language. Research Gap Type confusion weaknesses have received some attention by applied researchers and major software vendors for C and C++ code. Some publicly-reported vulnerabilities probably have type confusion as a root-cause weakness, but these may be described as "memory corruption" instead. For other languages, there are very few public reports of type confusion weaknesses. These are probably under-studied. Since many programs rely directly or indirectly on loose typing, a potential "type confusion" behavior might be intentional, possibly requiring more manual analysis.
CWE-481: Assigning instead of Comparing
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.
×
Edit Custom FilterThe code uses an operator for assignment when the intention was to perform a comparison.
In many languages the compare statement is very close in appearance to the assignment statement and are often confused. This bug is generally the result of a typo and usually causes obvious problems with program execution. If the comparison is in an if statement, the if statement will usually evaluate the value of the right-hand side of the predicate.
![]()
![]() ![]()
![]()
![]() Languages C (Undetermined Prevalence) C++ (Undetermined Prevalence) Java (Undetermined Prevalence) C# (Undetermined Prevalence) Example 1 The following C/C++ and C# examples attempt to validate an int input parameter against the integer value 100. (bad code)
Example Language: C
int isValid(int value) {
if (value=100) { }printf("Value is valid\n"); }return(1); printf("Value is not valid\n"); return(0); (bad code)
Example Language: C#
bool isValid(int value) {
if (value=100) { }Console.WriteLine("Value is valid."); }return true; Console.WriteLine("Value is not valid."); return false; However, the expression to be evaluated in the if statement uses the assignment operator "=" rather than the comparison operator "==". The result of using the assignment operator instead of the comparison operator causes the int variable to be reassigned locally and the expression in the if statement will always evaluate to the value on the right hand side of the expression. This will result in the input value not being properly validated, which can cause unexpected results. Example 2 In this example, we show how assigning instead of comparing can impact code when values are being passed by reference instead of by value. Consider a scenario in which a string is being processed from user input. Assume the string has already been formatted such that different user inputs are concatenated with the colon character. When the processString function is called, the test for the colon character will result in an insertion of the colon character instead, adding new input separators. Since the string was passed by reference, the data sentinels will be inserted in the original string (CWE-464), and further processing of the inputs will be altered, possibly malformed.. (bad code)
Example Language: C
void processString (char *str) {
int i;
for(i=0; i<strlen(str); i++) { if (isalnum(str[i])){ }processChar(str[i]); }else if (str[i] = ':') { movingToNewInput();} }Example 3 The following Java example attempts to perform some processing based on the boolean value of the input parameter. However, the expression to be evaluated in the if statement uses the assignment operator "=" rather than the comparison operator "==". As with the previous examples, the variable will be reassigned locally and the expression in the if statement will evaluate to true and unintended processing may occur. (bad code)
Example Language: Java
public void checkValid(boolean isValid) {
if (isValid = true) { }System.out.println("Performing processing"); }doSomethingImportant(); else { System.out.println("Not Valid, do not perform processing"); }return; While most Java compilers will catch the use of an assignment operator when a comparison operator is required, for boolean variables in Java the use of the assignment operator within an expression is allowed. If possible, try to avoid using comparison operators on boolean variables in java. Instead, let the values of the variables stand for themselves, as in the following code. (good code)
Example Language: Java
public void checkValid(boolean isValid) {
if (isValid) { }System.out.println("Performing processing"); }doSomethingImportant(); else { System.out.println("Not Valid, do not perform processing"); }return; Alternatively, to test for false, just use the boolean NOT operator. (good code)
Example Language: Java
public void checkValid(boolean isValid) {
if (!isValid) { }System.out.println("Not Valid, do not perform processing"); }return; System.out.println("Performing processing"); doSomethingImportant(); Example 4 The following example demonstrates the weakness. (bad code)
Example Language: C
void called(int foo){
if (foo=1) printf("foo\n"); }int main() { called(2); return 0;
![]()
CWE-587: Assignment of a Fixed Address to a Pointer
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.
×
Edit Custom Filter
Using a fixed address is not portable, because that address will probably not be valid in all environments or platforms.
![]()
![]() ![]()
![]() ![]()
![]()
![]() Languages C (Undetermined Prevalence) C++ (Undetermined Prevalence) C# (Undetermined Prevalence) Class: Assembly (Undetermined Prevalence) Example 1 This code assumes a particular function will always be found at a particular address. It assigns a pointer to that address and calls the function. (bad code)
Example Language: C
int (*pt2Function) (float, char, char)=0x08040000;
int result2 = (*pt2Function) (12, 'a', 'b'); // Here we can inject code to execute. The same function may not always be found at the same memory address. This could lead to a crash, or an attacker may alter the memory at the expected address, leading to arbitrary code execution.
![]()
CWE-805: Buffer Access with Incorrect Length Value
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.
×
Edit Custom FilterThe product uses a sequential operation to read or write a buffer, but it uses an incorrect length value that causes it to access memory that is outside of the bounds of the buffer.
When the length value exceeds the size of the destination, a buffer overflow could occur.
![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]()
![]() Languages C (Often Prevalent) C++ (Often Prevalent) Class: Assembly (Undetermined Prevalence) Example 1 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); This function allocates a buffer of 64 bytes to store the hostname under the assumption that the maximum length value of hostname is 64 bytes, however there is no guarantee that the hostname will not be larger than 64 bytes. If an attacker specifies an address which resolves to a very large hostname, then the function may overwrite sensitive data or even relinquish control flow to the attacker. Note that this example also contains an unchecked return value (CWE-252) that can lead to a NULL pointer dereference (CWE-476). 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 In the following example, the source character string is copied to the dest character string using the method strncpy. (bad code)
Example Language: C
...
char source[21] = "the character string"; char dest[12]; strncpy(dest, source, sizeof(source)-1); ... However, in the call to strncpy the source character string is used within the sizeof call to determine the number of characters to copy. This will create a buffer overflow as the size of the source character string is greater than the dest character string. The dest character string should be used within the sizeof call to ensure that the correct number of characters are copied, as shown below. (good code)
Example Language: C
...
char source[21] = "the character string"; char dest[12]; strncpy(dest, source, sizeof(dest)-1); ... Example 4 In this example, the method outputFilenameToLog outputs a filename to a log file. The method arguments include a pointer to a character string containing the file name and an integer for the number of characters in the string. The filename is copied to a buffer where the buffer size is set to a maximum size for inputs to the log file. The method then calls another method to save the contents of the buffer to the log file. (bad code)
Example Language: C
#define LOG_INPUT_SIZE 40
// saves the file name to a log file int outputFilenameToLog(char *filename, int length) { int success;
// buffer with size set to maximum size for input to log file char buf[LOG_INPUT_SIZE]; // copy filename to buffer strncpy(buf, filename, length); // save to log file success = saveToLogFile(buf); return success; However, in this case the string copy method, strncpy, mistakenly uses the length method argument to determine the number of characters to copy rather than using the size of the local character string, buf. This can lead to a buffer overflow if the number of characters contained in character string pointed to by filename is larger then the number of characters allowed for the local character string. The string copy method should use the buf character string within a sizeof call to ensure that only characters up to the size of the buf array are copied to avoid a buffer overflow, as shown below. (good code)
Example Language: C
...
// copy filename to buffer strncpy(buf, filename, sizeof(buf)-1); ... Example 5 Windows provides the MultiByteToWideChar(), WideCharToMultiByte(), UnicodeToBytes(), and BytesToUnicode() functions to convert between arbitrary multibyte (usually ANSI) character strings and Unicode (wide character) strings. The size arguments to these functions are specified in different units, (one in bytes, the other in characters) making their use prone to error. In a multibyte character string, each character occupies a varying number of bytes, and therefore the size of such strings is most easily specified as a total number of bytes. In Unicode, however, characters are always a fixed size, and string lengths are typically given by the number of characters they contain. Mistakenly specifying the wrong units in a size argument can lead to a buffer overflow. The following function takes a username specified as a multibyte string and a pointer to a structure for user information and populates the structure with information about the specified user. Since Windows authentication uses Unicode for usernames, the username argument is first converted from a multibyte string to a Unicode string. (bad code)
Example Language: C
void getUserInfo(char *username, struct _USER_INFO_2 info){
WCHAR unicodeUser[UNLEN+1]; }MultiByteToWideChar(CP_ACP, 0, username, -1, unicodeUser, sizeof(unicodeUser)); NetUserGetInfo(NULL, unicodeUser, 2, (LPBYTE *)&info); This function incorrectly passes the size of unicodeUser in bytes instead of characters. The call to MultiByteToWideChar() can therefore write up to (UNLEN+1)*sizeof(WCHAR) wide characters, or (UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) bytes, to the unicodeUser array, which has only (UNLEN+1)*sizeof(WCHAR) bytes allocated. If the username string contains more than UNLEN characters, the call to MultiByteToWideChar() will overflow the buffer unicodeUser.
![]()
CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
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.
×
Edit Custom FilterThe product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.
A buffer overflow condition exists when a product attempts to put more data in a buffer than it can hold, or when it attempts to put data in a memory area outside of the boundaries of a buffer. The simplest type of error, and the most common cause of buffer overflows, is the "classic" case in which the product copies the buffer without restricting how much is copied. Other variants exist, but the existence of a classic overflow strongly suggests that the programmer is not considering even the most basic of security protections.
![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]()
![]() Languages C (Undetermined Prevalence) C++ (Undetermined Prevalence) Class: Assembly (Undetermined Prevalence) Example 1 The following code asks the user to enter their last name and then attempts to store the value entered in the last_name array. (bad code)
Example Language: C
char last_name[20];
printf ("Enter your last name: "); scanf ("%s", last_name); The problem with the code above is that it does not restrict or limit the size of the name entered by the user. If the user enters "Very_very_long_last_name" which is 24 characters long, then a buffer overflow will occur since the array can only hold 20 characters total. Example 2 The following code attempts to create a local copy of a buffer to perform some manipulations to the data. (bad code)
Example Language: C
void manipulate_string(char * string){
char buf[24]; }strcpy(buf, string); ... However, the programmer does not ensure that the size of the data pointed to by string will fit in the local buffer and copies the data with the potentially dangerous strcpy() function. This may result in a buffer overflow condition if an attacker can influence the contents of the string parameter. Example 3 The code below calls the gets() function to read in data from the command line. (bad code)
Example Language: C
char buf[24]; }printf("Please enter your name and press <Enter>\n"); gets(buf); ... However, gets() is inherently unsafe, because it copies all input from STDIN to the buffer without checking size. This allows the user to provide a string that is larger than the buffer size, resulting in an overflow condition. Example 4 In the following example, a server accepts connections from a client and processes the client request. After accepting a client connection, the program will obtain client information using the gethostbyaddr method, copy the hostname of the client that connected to a local variable and output the hostname of the client to a log file. (bad code)
Example Language: C
...
struct hostent *clienthp;
char hostname[MAX_LEN]; // create server socket, bind to server address and listen on socket ... // accept client connections and process requests int count = 0; for (count = 0; count < MAX_CONNECTIONS; count++) { int clientlen = sizeof(struct sockaddr_in); int clientsocket = accept(serversocket, (struct sockaddr *)&clientaddr, &clientlen); if (clientsocket >= 0) { clienthp = gethostbyaddr((char*) &clientaddr.sin_addr.s_addr, sizeof(clientaddr.sin_addr.s_addr), AF_INET);
strcpy(hostname, clienthp->h_name); logOutput("Accepted client connection from host ", hostname); // process client request ... close(clientsocket); close(serversocket); ... However, the hostname of the client that connected may be longer than the allocated size for the local hostname variable. This will result in a buffer overflow when copying the client hostname to the local variable using the strcpy method.
![]()
Relationship
At the code level, stack-based and heap-based overflows do not differ significantly, so there usually is not a need to distinguish them. From the attacker perspective, they can be quite different, since different techniques are required to exploit them.
Terminology
Many issues that are now called "buffer overflows" are substantively different than the "classic" overflow, including entirely different bug types that rely on overflow exploit techniques, such as integer signedness errors, integer overflows, and format string bugs. This imprecise terminology can make it difficult to determine which variant is being reported.
|