logo

Incorrect Calculation

Draft Pillar
Structure: Simple
Description

This vulnerability occurs when software performs a calculation that produces wrong or unexpected results, which are then used to make security decisions or manage critical resources.

Extended Description

Incorrect calculations can directly lead to serious security flaws, such as misallocating memory, granting incorrect permissions, or failing authentication checks. These errors often stem from issues like integer overflows, off-by-one mistakes, or incorrect type conversions during critical operations. When these flawed results feed into security mechanisms, the consequences can escalate significantly. A simple math error might disable a protection feature, allow unauthorized access, or in severe cases, create conditions that enable remote code execution or complete system compromise.
Common Consequences 4
Scope: Availability

Impact: DoS: Crash, Exit, or Restart

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

Scope: IntegrityConfidentialityAvailability

Impact: DoS: Crash, Exit, or RestartDoS: 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 (Improper Restriction of Operations within the Bounds of a Memory Buffer) leading to a crash or even arbitrary code execution. Alternatively, it may result in an integer overflow (Integer Overflow or Wraparound) and / or a resource consumption problem (Uncontrolled Resource Consumption).

Scope: Access Control

Impact: Gain Privileges or Assume Identity

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

Scope: Access Control

Impact: Bypass Protection Mechanism

If the incorrect calculation leads to an insufficient comparison (Incorrect Comparison), it may compromise a protection mechanism such as a validation routine and allow an attacker to bypass the security-critical code.
Detection Methods 1
Manual AnalysisHigh
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 (Integer Overflow or Wraparound) or similar weaknesses that might have serious security impacts on the program.
Potential Mitigations 8
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

Strategy: Language Selection

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: Architecture and Design

Strategy: 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 product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.
Demonstrative Examples 3

ID : DX-33

The following image processing code allocates a table for images.

Code Example:

Bad
C
c
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 (Integer Overflow or Wraparound). 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 (Improper Restriction of Operations within the Bounds of a Memory Buffer).
This code attempts to calculate a football team's average number of yards gained per touchdown.

Code Example:

Bad
Java
java
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.

ID : DX-55

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

Code Example:

Bad
C
c
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.
Observed Examples 2
CVE-2020-0022chain: mobile phone Bluetooth implementation does not include offset when calculating packet length (Incorrect Calculation), leading to out-of-bounds write (Out-of-bounds Write)
CVE-2004-1363substitution overflow: buffer overflow using environment variables that are expanded after the length check is performed
References 3
SafeInt
David LeBlanc and Niels Dekker
https://github.com/dcleblanc/SafeInt/(2025-07-29)
ID: REF-106
24 Deadly Sins of Software Security
Michael Howard, David LeBlanc, and John Viega
McGraw-Hill
2010
ID: REF-44
The Art of Software Security Assessment
Mark Dowd, John McDonald, and Justin Schuh
Addison Wesley
2006
ID: REF-62
Likelihood of Exploit

High

Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Technologies:
Not Technology-Specific : Undetermined
Modes of Introduction
Implementation
Related Attack Patterns
Related Weaknesses
CanPrecede: Improper Null Termination (CWE-170)
Taxonomy Mapping
  • CERT C Secure Coding
  • CERT C Secure Coding
  • CERT C Secure Coding
  • CERT C Secure Coding
  • CERT C Secure Coding
Notes
Research Gap Weaknesses related to this Pillar appear to be under-studied, especially with respect to classification schemes. Input from academic and other communities could help identify and resolve gaps or organizational difficulties within CWE.