Some products use signed integers or floats even when their values are only expected to be positive or 0. An input validation check might assume that the value is positive, and only check for the maximum value. If the value is negative, but the code assumes that the value is positive, this can produce an error. The error may have security consequences if the negative value is used for memory allocation, array access, buffer access, etc. Ultimately, the error could lead to a buffer overflow or other type of memory corruption.
The use of a negative number in a positive-only context could have security implications for other types of resources. For example, a shopping cart might check that the user is not requesting more than 10 items, but a request for -3 items could cause the application to calculate a negative price and credit the attacker's account.
| Impact | Details |
|---|---|
|
Modify Application Data; Execute Unauthorized Code or Commands |
Scope: Integrity, Confidentiality, Availability
An attacker could modify the structure of the message or data being sent to the downstream component, possibly injecting commands.
|
|
DoS: Resource Consumption (Other) |
Scope: Availability
in some contexts, a negative value could lead to resource consumption.
|
|
Modify Memory; Read Memory |
Scope: Confidentiality, Integrity
If a negative value is used to access memory, buffers, or other indexable structures, it could access memory outside the bounds of the buffer.
|
| Phase(s) | Mitigation |
|---|---|
|
Implementation |
Strategy: Enforcement by Conversion If the number to be used is always expected to be positive, change the variable type from signed to unsigned or size_t.
|
|
Implementation |
Strategy: Input Validation If the number to be used could have a negative value based on the specification (thus requiring a signed value), but the number should only be positive to preserve code correctness, then include a check to ensure that the value is positive.
|
| Nature | Type | ID | Name |
|---|---|---|---|
| ChildOf | Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. | 1023 | Incomplete Comparison with Missing Factors |
| CanPrecede | Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. | 119 | Improper Restriction of Operations within the Bounds of a Memory Buffer |
| CanPrecede | Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. | 124 | Buffer Underwrite ('Buffer Underflow') |
| CanPrecede | Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. | 195 | Signed to Unsigned Conversion Error |
| CanPrecede | Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. | 682 | Incorrect Calculation |
| Nature | Type | ID | Name |
|---|---|---|---|
| MemberOf | Category Category - a CWE entry that contains a set of other entries that share a common characteristic. | 189 | Numeric Errors |
C (Often Prevalent)
C++ (Often Prevalent)
Example 1
The following code is intended to read an incoming packet from a socket and extract one or more headers.
The code performs a check to make sure that the packet does not contain too many headers. However, numHeaders is defined as a signed int, so it could be negative. If the incoming packet specifies a value such as -3, then the malloc calculation will generate a negative number (say, -300 if each header can be a maximum of 100 bytes). When this result is provided to malloc(), it is first converted to a size_t type. This conversion then produces a large value such as 4294966996, which may cause malloc() to fail or to allocate an extremely large amount of memory (CWE-195). With the appropriate negative numbers, an attacker could trick malloc() into using a very small positive number, which then allocates a buffer that is much smaller than expected, potentially leading to a buffer overflow.
Example 2
The following code reads a maximum size and performs a sanity check on that size. It then performs a strncpy, assuming it will not exceed the boundaries of the array. While the use of "short s" is forced in this particular example, short int's are frequently used within real-world code, such as code that processes structured data.
This code first exhibits an example of CWE-839, allowing "s" to be a negative number. When the negative short "s" is converted to an unsigned integer, it becomes an extremely large positive integer. When this converted integer is used by strncpy() it will lead to a buffer overflow (CWE-119).
Example 3
In the following code, the method retrieves a value from an array at a specific array index location that is given as an input parameter to the method
However, this method only verifies that the given array index is less than the maximum length of the array but does not check for the minimum value (CWE-839). This will allow a negative value to be accepted as the input array index, which will result in reading data before the beginning of the buffer (CWE-127) and may allow access to sensitive memory. The input array index should be checked to verify that is within the maximum and minimum range required for the array (CWE-129). In this example the if statement should be modified to include a minimum range check, as shown below.
Example 4
The following code shows a simple BankAccount class with deposit and withdraw methods.
The withdraw method includes a check to ensure that the withdrawal amount does not exceed the maximum limit allowed, however the method does not check to ensure that the withdrawal amount is greater than a minimum value (CWE-129). Performing a range check on a value that does not include a minimum check can have significant security implications, in this case not including a minimum range check can allow a negative value to be used which would cause the financial application using this class to deposit money into the user account rather than withdrawing. In this example the if statement should the modified to include a minimum range check, as shown below.
Note that this example does not protect against concurrent access to the BankAccount balance variable, see CWE-413 and CWE-362.
While it is out of scope for this example, note that the use of doubles or floats in financial calculations may be subject to certain kinds of attacks where attackers use rounding errors to steal money.
Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
| Reference | Description |
|---|---|
|
Chain: 16-bit counter can be interpreted as a negative value, compared to a 32-bit maximum value, leading to buffer under-write.
|
|
|
Chain: kernel's lack of a check for a negative value leads to memory corruption.
|
|
|
Chain: parser uses atoi() but does not check for a negative value, which can happen on some platforms, leading to buffer under-write.
|
|
|
Chain: Negative value stored in an int bypasses a size check and causes allocation of large amounts of memory.
|
|
|
Chain: negative offset value to IOCTL bypasses check for maximum index, then used as an array index for buffer under-read.
|
|
|
chain: file transfer client performs signed comparison, leading to integer overflow and heap-based buffer overflow.
|
|
|
chain: negative ID in media player bypasses check for maximum index, then used as an array index for buffer under-read.
|
| Nature | Type | ID | Name |
|---|---|---|---|
| MemberOf | ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). | 884 | CWE Cross-section |
| MemberOf | CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. | 1397 | Comprehensive Categorization: Comparison |
Rationale
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.Comments
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.| Submissions | ||
|---|---|---|
| Submission Date | Submitter | Organization |
|
2011年03月24日
(CWE 1.12, 2011年03月30日) |
CWE Content Team | MITRE |
| Modifications | ||
| Modification Date | Modifier | Organization |
|
2025年09月09日
(CWE 4.18, 2025年09月09日) |
CWE Content Team | MITRE |
| updated Demonstrative_Examples | ||
| 2023年10月26日 | CWE Content Team | MITRE |
| updated Observed_Examples | ||
| 2023年06月29日 | CWE Content Team | MITRE |
| updated Mapping_Notes | ||
| 2023年04月27日 | CWE Content Team | MITRE |
| updated Relationships | ||
| 2023年01月31日 | CWE Content Team | MITRE |
| updated Alternate_Terms, Description | ||
| 2019年01月03日 | CWE Content Team | MITRE |
| updated Relationships | ||
| 2018年03月27日 | CWE Content Team | MITRE |
| updated Description | ||
| 2014年02月18日 | CWE Content Team | MITRE |
| updated Relationships | ||
| 2012年05月11日 | CWE Content Team | MITRE |
| updated Demonstrative_Examples, References, Relationships | ||
| 2011年06月01日 | CWE Content Team | MITRE |
| updated Common_Consequences | ||
Use of the Common Weakness Enumeration (CWE™) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006–2025, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.