CWE-681: Incorrect Conversion between Numeric Types

Description

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.

Potential Impact

Other, Integrity

Unexpected State, Quality Degradation

Demonstrative Examples

In the following Java example, a float literal is cast to an integer, thus causing a loss of precision.

Bad

int i = (int) 33457.8f;

This code adds a float and an integer together, casting the result to an integer.

Bad

$floatVal = 1.8345;$intVal = 3;$result = (int)$floatVal + $intVal;

Normally, PHP will preserve the precision of this operation, making $result = 4.8345. After the cast to int, it is reasonable to expect PHP to follow rounding convention and set $result = 5. However, the explicit cast to int always rounds DOWN, so the final value of $result is 4. This behavior may have unintended consequences.

In this example the variable amount can hold a negative value when it is returned. Because the function is declared to return an unsigned int, amount will be implicitly converted to unsigned.

Bad

unsigned int readdata () {int amount = 0;...if (result == ERROR)amount = -1;...return amount;}

If the error condition in the code above is met, then the return value of readdata() will be 4,294,967,295 on a system that uses 32-bit integers.

In this example, depending on the return value of accecssmainframe(), the variable amount can hold a negative value when it is returned. Because the function is declared to return an unsigned value, amount will be implicitly cast to an unsigned number.

Bad

unsigned int readdata () {int amount = 0;...amount = accessmainframe();...return amount;}

If the return value of accessmainframe() is -1, then the return value of readdata() will be 4,294,967,295 on a system that uses 32-bit integers.

Mitigations & Prevention

Implementation

Avoid making conversion between numeric types. Always check for the allowed ranges.

Detection Methods

Automated Static Analysis High — Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then sea

Real-World CVE Examples

CVE ID	Description
CVE-2022-2639	Chain: integer coercion error (CWE-192) prevents a return value from indicating an error, leading to out-of-bounds write (CWE-787)
CVE-2021-43537	Chain: in a web browser, an unsigned 64-bit integer is forcibly cast to a 32-bit integer (CWE-681) and potentially leading to an integer overflow (CWE-190). If an integer overflow occurs, this can cau
CVE-2007-4268	Chain: integer signedness error (CWE-195) passes signed comparison, leading to heap overflow (CWE-122)
CVE-2007-4988	Chain: signed short width value in image processor is sign extended during conversion to unsigned int, which leads to integer overflow and heap-based buffer overflow.
CVE-2009-0231	Integer truncation of length value leads to heap-based buffer overflow.
CVE-2008-3282	Size of a particular type changes for 64-bit platforms, leading to an integer truncation in document processor causes incorrect index to be generated.

Taxonomy Mappings

CERT C Secure Coding: FLP34-C — Ensure that floating point conversions are within range of the new type
CERT C Secure Coding: INT15-C — Use intmax_t or uintmax_t for formatted IO on programmer-defined integer types
CERT C Secure Coding: INT31-C — Ensure that integer conversions do not result in lost or misinterpreted data
CERT C Secure Coding: INT35-C — Evaluate integer expressions in a larger size before comparing or assigning to that size
The CERT Oracle Secure Coding Standard for Java (2011): NUM12-J — Ensure conversions of numeric types to narrower types do not result in lost or misinterpreted data
Software Fault Patterns: SFP1 — Glitch in computation
OMG ASCSM: ASCSM-CWE-681 —

Frequently Asked Questions

What is CWE-681?

CWE-681 (Incorrect Conversion between Numeric Types) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. 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 cont...

How can CWE-681 be exploited?

Attackers can exploit CWE-681 (Incorrect Conversion between Numeric Types) to unexpected state, quality degradation. This weakness is typically introduced during the Implementation phase of software development.

How do I prevent CWE-681?

Key mitigations include: Avoid making conversion between numeric types. Always check for the allowed ranges.

What is the severity of CWE-681?

CWE-681 is classified as a Base-level weakness (Medium abstraction). It has been observed in 6 real-world CVEs.