CWE-14: Compiler Removal of Code to Clear Buffers
Sensitive memory is cleared according to the source code, but compiler optimizations leave the memory untouched when it is not read from again, aka "dead store removal."
Browse cwe for c++ with official CWE context and Glexia analysis.
Search And Filters
Showing 50 of 97 CWE records · Page 1 of 2.
Sensitive memory is cleared according to the source code, but compiler optimizations leave the memory untouched when it is not read from again, aka "dead store removal."
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.
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.
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).
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().
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.
The product writes to a buffer using an index or pointer that references a memory location prior to the beginning of the buffer.
The product reads data past the end, or before the beginning, of the intended buffer.
The product reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations after the targeted buffer.
The product reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations prior to the targeted buffer.
Wrap around errors occur whenever a value is incremented past the maximum value for its type and therefore "wraps around" to a very small, negative, or undefined value.
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.
The product parses a formatted message or structure, but it does not handle or incorrectly handles a length field that is inconsistent with the actual length of the associated data.
The product does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow.
The product uses a function that accepts a format string as an argument, but the format string originates from an external source.
The product does not correctly calculate the length of strings that can contain wide or multi-byte characters.
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes NUL characters or null bytes when they are sent to a downstream component.
The product does not terminate or incorrectly terminates a string or array with a null character or equivalent terminator.
The product makes invalid assumptions about how protocol data or memory is organized at a lower level, resulting in unintended program behavior.
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 coercion refers to a set of flaws pertaining to the type casting, extension, or truncation of primitive data types.
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.
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.
The product uses an unsigned primitive and performs a cast to a signed primitive, which can produce an unexpected value if the value of the unsigned primitive can not be represented using a signed primitive.
Truncation errors occur when a primitive is cast to a primitive of a smaller size and data is lost in the conversion.
The product calls a function that can never be guaranteed to work safely.
The product uses the chroot() system call to create a jail, but does not change the working directory afterward. This does not prevent access to files outside of the jail.
Using realloc() to resize buffers that store sensitive information can leave the sensitive information exposed to attack, because it is not removed from memory.
An exception is thrown from a function, but it is not caught.
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
The product uses a signal handler that introduces a race condition.
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.
The product sends non-cloned mutable data as an argument to a method or function.
Sending non-cloned mutable data as a return value may result in that data being altered or deleted by the calling function.
Catching overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.
The product throws or raises an overly broad exceptions that can hide important details and produce inappropriate responses to certain conditions.
The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.
The product calls free() twice on the same memory address.
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.
The code uses a variable that has not been initialized, leading to unpredictable or unintended results.
The product does not clean up its state or incorrectly cleans up its state when an exception is thrown, leading to unexpected state or control flow.
Duplicate keys in associative lists can lead to non-unique keys being mistaken for an error.
The accidental deletion of a data-structure sentinel can cause serious programming logic problems.
The accidental addition of a data-structure sentinel can cause serious programming logic problems.
A function can return a pointer to memory that is outside of the buffer that the pointer is expected to reference.
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.
In C and C++, one may often accidentally refer to the wrong memory due to the semantics of when math operations are implicitly scaled.
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.
The product dereferences a pointer that it expects to be valid but is NULL.
The code does not have a default case in an expression with multiple conditions, such as a switch statement.