Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (2.10)  

CWE-682: Incorrect Calculation

Weakness ID: 682
Abstraction: Class
Status: Draft
Presentation Filter:
+ Description

Description Summary

The software performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.

Extended Description

When software performs a security-critical calculation incorrectly, it might lead to incorrect resource allocations, incorrect privilege assignments, or failed comparisons among other things. Many of the direct results of an incorrect calculation can lead to even larger problems such as failed protection mechanisms or even arbitrary code execution.

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms



+ Common Consequences

Technical Impact: DoS: crash / exit / restart

If the incorrect calculation causes the program to move into an unexpected state, it may lead to a crash or impairment of service.


Technical Impact: DoS: crash / exit / restart; DoS: resource consumption (other); Execute unauthorized code or commands

If the incorrect calculation is used in the context of resource allocation, it could lead to an out-of-bounds operation (CWE-119) leading to a crash or even arbitrary code execution. Alternatively, it may result in an integer overflow (CWE-190) and / or a resource consumption problem (CWE-400).

Access Control

Technical Impact: Gain privileges / assume identity

In the context of privilege or permissions assignment, an incorrect calculation can provide an attacker with access to sensitive resources.

Access Control

Technical Impact: Bypass protection mechanism

If the incorrect calculation leads to an insufficient comparison (CWE-697), it may compromise a protection mechanism such as a validation routine and allow an attacker to bypass the security-critical code.

+ Likelihood of Exploit


+ Detection Methods

Manual Analysis

This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.

Specifically, manual static analysis is useful for evaluating the correctness of allocation calculations. This can be useful for detecting overflow conditions (CWE-190) or similar weaknesses that might have serious security impacts on the program.

Effectiveness: High

These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

+ Demonstrative Examples

Example 1

The following image processing code allocates a table for images.

(Bad Code)
Example Language:
img_t table_ptr; /*struct containing img data, 10kB each*/
int num_imgs;
num_imgs = get_num_imgs();
table_ptr = (img_t*)malloc(sizeof(img_t)*num_imgs);

This code intends to allocate a table of size num_imgs, however as num_imgs grows large, the calculation determining the size of the list will eventually overflow (CWE-190). This will result in a very small list to be allocated instead. If the subsequent code operates on the list as if it were num_imgs long, it may result in many types of out-of-bounds problems (CWE-119).

Example 2

This code attempts to calculate a football team's average number of yards gained per touchdown.

(Bad Code)
Example Language: Java 
int touchdowns = team.getTouchdowns();
int yardsGained = team.getTotalYardage();
System.out.println(team.getName() + " averages " + yardsGained / touchdowns + "yards gained for every touchdown scored");
The code does not consider the event that the team they are querying has not scored a touchdown, but has gained yardage. In that case, we should expect an ArithmeticException to be thrown by the JVM. This could lead to a loss of availability if our error handling code is not set up correctly.

Example 3

This example attempts to calculate the position of the second byte of a pointer.

(Bad Code)
Example Language:
int *p = x;
char * second_char = (char *)(p + 1);

In this example, second_char is intended to point to the second byte of p. But, adding 1 to p actually adds sizeof(int) to p, giving a result that is incorrect (3 bytes off on 32-bit platforms). If the resulting memory address is read, this could potentially be an information leak. If it is a write, it could be a security-critical write to unauthorized memory-- whether or not it is a buffer overflow. Note that the above code may also be wrong in other ways, particularly in a little endian environment.

+ Potential Mitigations

Phase: Implementation

Understand your programming language's underlying representation and how it interacts with numeric calculation. Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, "not-a-number" calculations, and how your language handles numbers that are too large or too small for its underlying representation.

Phase: Implementation

Strategy: Input Validation

Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range.

Phase: Implementation

Use the appropriate type for the desired action. For example, in C/C++, only use unsigned types for values that could never be negative, such as height, width, or other numbers related to quantity.

Phase: Architecture and Design

Strategies: Language Selection; Libraries or Frameworks

Use languages, libraries, or frameworks that make it easier to handle numbers without unexpected consequences.

Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++).

Phase: Implementation

Strategy: Compilation or Build Hardening

Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system.

Phase: Testing

Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible.

Phase: Testing

Use dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory189Numeric Errors
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory738CERT C Secure Coding Section 04 - Integers (INT)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory739CERT C Secure Coding Section 05 - Floating Point (FLP)
Weaknesses Addressed by the CERT C Secure Coding Standard734
ChildOfCategoryCategory7522009 Top 25 - Risky Resource Management
Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750
ChildOfCategoryCategory872CERT C++ Secure Coding Section 04 - Integers (INT)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory873CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)
Weaknesses Addressed by the CERT C++ Secure Coding Standard868
ChildOfCategoryCategory977SFP Secondary Cluster: Design
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness BaseWeakness Base170Improper Null Termination
Research Concepts1000
ParentOfWeakness BaseWeakness Base128Wrap-around Error
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base131Incorrect Calculation of Buffer Size
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base135Incorrect Calculation of Multi-Byte String Length
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base190Integer Overflow or Wraparound
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness BaseWeakness Base191Integer Underflow (Wrap or Wraparound)
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfCategoryCategory192Integer Coercion Error
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base193Off-by-one Error
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base369Divide By Zero
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness VariantWeakness Variant467Use of sizeof() on a Pointer Type
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base468Incorrect Pointer Scaling
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base469Use of Pointer Subtraction to Determine Size
Research Concepts (primary)1000
MemberOfViewView1000Research Concepts
Research Concepts (primary)1000
CanFollowWeakness BaseWeakness Base681Incorrect Conversion between Numeric Types
Research Concepts1000
CanFollowWeakness BaseWeakness Base839Numeric Range Comparison Without Minimum Check
Research Concepts1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingFLP32-CPrevent or detect domain and range errors in math functions
CERT C Secure CodingFLP33-CConvert integers to floating point for floating point operations
CERT C Secure CodingINT07-CUse only explicitly signed or unsigned char type for numeric values
CERT C Secure CodingINT13-CUse bitwise operators only on unsigned operands
CERT C++ Secure CodingINT07-CPPUse only explicitly signed or unsigned char type for numeric values
CERT C++ Secure CodingINT10-CPPDo not assume a positive remainder when using the % operator
CERT C++ Secure CodingINT13-CPPUse bitwise operators only on unsigned operands
CERT C++ Secure CodingFLP32-CPPPrevent or detect domain and range errors in math functions
CERT C++ Secure CodingFLP33-CPPConvert integers to floating point for floating point operations
+ References
[REF-18] David LeBlanc and Niels Dekker. "SafeInt". <>.
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 7: Integer Overflows." Page 119. McGraw-Hill. 2010.
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 6, "Signed Integer Boundaries", Page 220.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submission DateSubmitterOrganizationSource
Internal CWE Team
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships
2008-10-14CWE Content TeamMITREInternal
updated Type
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Potential_Mitigations, Relationships
2009-03-10CWE Content TeamMITREInternal
updated Potential_Mitigations
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITREInternal
updated Demonstrative_Examples, Related_Attack_Patterns
2009-10-29CWE Content TeamMITREInternal
updated Demonstrative_Examples, Relationships
2010-02-16CWE Content TeamMITREInternal
updated Potential_Mitigations
2010-04-05CWE Content TeamMITREInternal
updated Detection_Factors, Potential_Mitigations, References
2010-06-21CWE Content TeamMITREInternal
updated Potential_Mitigations
2010-09-27CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-03-29CWE Content TeamMITREInternal
updated Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Demonstrative_Examples, References, Relationships
2014-02-18CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships
2015-12-07CWE Content TeamMITREInternal
updated Relationships
2017-01-19CWE Content TeamMITREInternal
updated Applicable_Platforms

More information is available — Please select a different filter.
Page Last Updated: January 18, 2017