Signed integer overflow is undefined behavior (see undefined behavior 33 in Annex J.2 of C99). This means that implementations have a great deal of 36. Consequently, implementations have considerable latitude in how they deal with signed integer overflow.

An implementation may define the same modulo arithmetic for both unsigned as well as signed integers. On such an implementation, signed integers overflow by wrapping around to zero. An example of such an implementation is GNU GCC invoked with the -fwrapv command line option.

Other implementations may cause a hardware trap (also referred to as an exceptional condition) to be generated when a signed integer overflows. On such implementations a program that causes a signed integer to overflow will most likely abnormally exit. On a UNIX system the result of such an event may be a signal sent to the process. An example of such an implementation is GNU GCC invoked with the -ftrapv command line option.

Other implementations still may simply assume that signed integers never overflow and generate object code accordingly. An example of such an implementation is GNU gcc invoked without either the -fwrapv or the -ftrapv option.

It is also possible for the same conforming implementation to emit code that exhibits different behavior in different contexts. For example, an implementation may determine that a signed integer loop control variable declared in a local scope cannot overflow and emit efficient code based on that determination, while the same implementation may avoid making that assumption in another function when the variable is a global object.

(See MSC15-C. Do not depend on undefined behavior.) An implementation that defines signed integer types as being modulo, for example, need not detect integer overflow. Implementations may also trap on signed arithmetic overflows, or simply assume that overflows will never happen and generate object code accordingly.  It is also possible for the same conforming implementation to emit code that exhibits different behavior in different contexts. For example, an implementation may determine that a signed integer loop control variable declared in a local scope cannot overflow and may emit efficient code on the basis of that determination, while the same implementation may determine that a global variable used in a similar context will wrap.

For these reasons, it is important to ensure that operations on signed integers do not result in overflow. Of particular importance For these reasons, it is important to ensure that operations on signed integers do no result in overflow. (See recommendation MSC15-C. Do not depend on undefined behavior.) Of particular importance, however, are operations on signed integer values that originate from untrusted sources a tainted source and are used in any of the following ways:as

• Integer operands of
• as an array index
• in any pointer arithmetic
• as a length or size of an object
• as the bound of an array (for example, a loop counter)
• , including array indexing
• The assignment expression for the declaration of a variable length array
• The postfix expression preceding square brackets [] or the expression in square brackets [] of a subscripted designation of an element of an array object
• Function arguments of type size_t or rsize_t (for example, as an argument to a memory allocation function
• in security-critical code
• )

Integer operations will Most integer operations can result in overflow if the resulting value cannot be represented by the underlying representation of the integer. The following table indicates which operators operations can result in overflow:.

The following sections examine specific operations that are susceptible to integer overflow. When operating on small integer types (smaller with less precision than int), integer promotions are applied. The usual arithmetic conversions may also be applied to (implicitly) convert operands to equivalent types before arithmetic operations are performed. Make sure you Programmers should understand integer conversion rules before trying to implement secure arithmetic operations. (See recommendation INT02-C. Understand integer conversion rules.) AnchorAdditionAddition

Addition

Addition is between two operands of arithmetic type or between a pointer to an object type and an integer type for rules about adding a pointer to an integer. (See rules ARR37-C. Do not add or subtract an integer to a pointer to a non-array object and ARR38-C. Do not add or subtract an integer to a pointer if the resulting value does not refer to a valid array element.) Incrementing is equivalent to adding one.

Noncompliant Code Example

This noncompliant code example may result in a signed integer overflow during the addition of the signed operands si1 and si2. If this behavior is unanticipated, it can lead to an exploitable vulnerability.

int si1, si2, sum;

/* Initialize si1 and si2 */

sum = si1 + si2;

Compliant Solution (Pre-Condition Test, Two's Complement)

This compliant solution performs a pre-condition test of the operands of the addition to ensure no overflow occurs, assuming two's complement representation.

signed int si1, si2, sum;

/* Initialize si1 and si2 */

if ( ((si1^si2) | (((si1^(~(si1^si2) & INT_MIN)) + si2)^si2)) >= 0) {
   /* handle error condition */
} else {
  sum = si1 + si2;
}

This compliant solution works only on architectures that use two's complement representation. While most modern platforms use two's complement representation, it is best not to introduce unnecessary platform dependencies. (See recommendation MSC14-C. Do not introduce unnecessary platform dependencies.) This solution can also be more expensive than a post-condition test, especially on RISC CPUs.

Compliant Solution (General)

This compliant solution tests the suspect addition operation to ensure no overflow occurs regardless of representation.

Implementation Details

GNU GCC invoked with the -fwrapv command-line option defines the same modulo arithmetic for both unsigned and signed integers.

GNU GCC invoked with the -ftrapv command-line option causes a trap to be generated when a signed integer overflows, which will most likely abnormally exit. On a UNIX system, the result of such an event may be a signal sent to the process.

GNU GCC invoked without either the -fwrapv or the -ftrapv option may simply assume that signed integers never overflow and may generate object code accordingly.

Atomic Integers

The C Standard defines the behavior of arithmetic on atomic signed integer types to use two's complement representation with silent wraparound on overflow; there are no undefined results. Although defined, these results may be unexpected and therefore carry similar risks to unsigned integer wrapping. (See INT30-C. Ensure that unsigned integer operations do not wrap.) Consequently, signed integer overflow of atomic integer types should also be prevented or detected. 

Addition

Addition is between two operands of arithmetic type or between a pointer to an object type and an integer type. This rule applies only to addition between two operands of arithmetic type. (See ARR37-C. Do not add or subtract an integer to a pointer to a non-array object and ARR30-C. Do not form or use out-of-bounds pointers or array subscripts.)

Incrementing is equivalent to adding 1.

Noncompliant Code Example

This noncompliant code example can result in a signed integer overflow during the addition of the signed operands si_a and si_b:

void func(signed int si_a, signed int si_b) {
  signed int sum = si_a + si_b;
  /* ... */
}

Compliant Solution

This compliant solution ensures that the addition operation cannot overflow, regardless of representation:

#include <limits.h>
 
void f(signed int si_a, signed int si_b) {
  signed int sum;
  if (((si_b > 0) && (si_a > (INT_MAX - si_b))) ||
      ((si_b < 0) && (si_a < (INT_MIN - si_b

signed int si1, si2, sum;

/* Initialize si1 and si2 */

if (((si2>0) && (si1 > (INT_MAX-si2)))
 || ((si2<0) && (si1 < (INT_MIN-si2)))) {
    /* handleHandle error condition */
  }
 else {
    sum = si1si_a + si2si_b;
}

This solution is more readable but may be less efficient than the solution that is specific to two's complement representation.

...

Subtraction

Subtraction is between two operands of arithmetic type, two pointers to qualified or unqualified versions of compatible object types, or between a pointer to an object type and an integer type. See rules ARR36-C. Do not subtract or compare two pointers that do not refer to the same array, ARR37-C. Do not add or subtract an integer to a pointer to a non-array object, and ARR38-C. Do not add or subtract an integer to a pointer if the resulting value does not refer to a valid array element for information about pointer subtraction. Decrementing is equivalent to subtracting one.

Noncompliant Code Example

This noncompliant code example can result in a signed integer overflow during the subtraction of the signed operands si1 and si2. If this behavior is unanticipated, the resulting value may be used to allocate insufficient memory for a subsequent operation or in some other manner that can lead to an exploitable vulnerability.

signed int si1, si2, result;

/* Initialize si1 and si2 */

result = si1 - si2;

...

  }
  /* ... */
}

Compliant Solution (GNU)

This compliant solution uses the GNU extension __builtin_sadd_overflow, available with GCC, Clang, and ICC:

void f(signed int si_a, signed int si_b) {
  signed int sum;
  if (__builtin_sadd_overflow(si_a, si_b, &sum)) {
    /* Handle error */
  }
  /* ... */
}

Subtraction

Subtraction is between two operands of arithmetic type, two pointers to qualified or unqualified versions of compatible object types, or a pointer to an object type and an integer type. This rule applies only to subtraction between two operands of arithmetic type. (See ARR36-C. Do not subtract or compare two pointers that do not refer to the same array, ARR37-C. Do not add or subtract an integer to a pointer to a non-array object, and ARR30-C. Do not form or use out-of-bounds pointers or array subscripts for information about pointer subtraction.)

Decrementing is equivalent to subtracting 1.

Noncompliant Code Example

This noncompliant code example can result in a signed integer overflow during the subtraction of the signed operands si_a and si_b:

void func(signed int si_a, signed int si_b) {
  signed int diff = si_a - si_b;
  /* ... */
}

Compliant Solution

This compliant solution tests the operands of the subtraction to guarantee there is no possibility of signed overflow, presuming two's complement representation.regardless of representation:

#include <limits.h>
 
void func(signed int si1si_a, si2, result;

/* Initialize si1 and si2 */

if (((si1^si2)
  & (((si1 ^ ((si1^si2) signed int si_b) {
  signed int diff;
  if ((si_b > 0 && si_a < INT_MIN + si_b) ||
    & (1 << (sizeof(int)*CHAR_BIT-1))))-si2)^si2))(si_b < 0) {
  /* handle error condition */
}
&& si_a > INT_MAX + si_b)) {
    /* Handle error */
  } else {
  result  diff = si1si_a - si2si_b;
  }

  /* ... */
}

This compliant solution only works on architectures that use two's complement representation. While most modern platforms use two's complement representation, it is best not to introduce unnecessary platform dependencies. (See recommendation MSC14-C. Do not introduce unnecessary platform dependencies.)

Compliant Solution (General)

Compliant Solution (GNU)

This compliant solution uses the GNU extension __builtin_ssub_overflow, available with GCC, Clang, and ICC:This compliant solution tests the operands of the subtraction to guarantee there is no possibility of signed overflow, regardless of representation.

void func(signed int si1si_a, si2, result;

/* Initialize si1 and si2 */

if ((si2 > 0 && si1 < INT_MIN + si2) ||signed int si_b) {
  signed int diff;
  if (__builtin_ssub_overflow(si_a, si_b, &diff)) {
    (si2/* <Handle 0 && si1 > INT_MAX + si2)) {error */
  }

  /* handle error condition */
}
else {
  result = si1 - si2;
}

...

... */
}

Multiplication

Multiplication

...

Multiplication is between two operands of arithmetic type.

Noncompliant Code Example

This noncompliant code example can result in a signed integer overflow during the multiplication of the signed operands si1 and si2. If this behavior is unanticipated, the resulting value may be used to allocate insufficient memory for a subsequent operation or in some other manner that can lead to an exploitable vulnerability. si_a and si_b:

void func(signed int si1, si2, result;

si_a, signed int si_b) {
  signed int result = si_a * si_b;
  /* ... */

result = si1 * si2;
}

Compliant Solution

The product of two operands can always be represented using twice the number of bits than exist in the precision of the larger of the two operands. This compliant solution guarantees there is no possibility of eliminates signed overflow on systems where long long is at least twice the size precision of int.:

#include <stddef.h>
signed int si1, si2, result;

/* Initialize si1 and si2 */

static_assert(
  sizeof(long long) >= 2 * sizeof(int),
  "Unable to detect overflow after multiplication"
);

#include <assert.h>
#include <limits.h>
#include <inttypes.h>
 
extern size_t popcount(uintmax_t);
#define PRECISION(umax_value) popcount(umax_value) 
  
void func(signed int si_a, signed int si_b) {
  signed int result;
  signed long long tmp;
 = (signed long long)si1 *assert(PRECISION(ULLONG_MAX) >= 2 * PRECISION(UINT_MAX));
  tmp = (signed long long)si_a * (signed long long)si_b;
 
  /*
   * If the product cannot be represented  (signed long long)si2;
/*
 * If the product cannot be represented as a as a 32-bit integer,
   * handle as an error condition.
   */
  if ( (tmp > INT_MAX) || (tmp < INT_MIN) ) {
    /* handleHandle error condition */
  }
 else {
    result = (int)tmp;
  }
  /* ... */
}

The compliant solution uses a static assertion to ensure that the overflow detection will succeed. See recommendation DCL03-C. Use a static assertion to test the value of a constant expression for a discussion of static assertions.assertion fails if long long has less than twice the precision of int. The  PRECISION() macro and popcount() function provide the correct precision for any integer type. (See INT35-C. Use correct integer precisions.)

Compliant Solution

The following portable compliant solution can be used with any conforming implementation, including those that do not have an integer type that is at least twice the precision of int:On systems where this relationship does not exist, the following compliant solution may be used to ensure signed overflow does not occur.

#include <limits.h>
 
void func(signed int si1si_a, si2, result;

/* Initialize si1 and si2 */

if (si1  signed int si_b) {
  signed int result;  
  if (si_a > 0) {  /* si1si_a is positive */
    if (si2si_b > 0) {  /* si1si_a and si2si_b are positive */
      if (si1si_a > (INT_MAX / si2si_b)) {
        /* handleHandle error condition */
    }
  } /*
 end if si1 and si2 are positive */
   } else { /* si1si_a positive, si2 non-positivesi_b nonpositive */
      if (si2si_b < (INT_MIN / si1si_a)) {
        /* handleHandle error condition */
      }
    } /* si1si_a positive, si2 non-positivesi_b nonpositive */
} /* end if si1 is positive */
 } else { /* si1si_a is non-positivenonpositive */
    if (si2si_b > 0) { /* si1si_a is non-positivenonpositive, si2si_b is positive */
      if (si1si_a < (INT_MIN / si2si_b)) {
        /* handleHandle error condition */
    }
  }
 /* end if si1 is non-positive, si2 is positive */
   } else { /* si1si_a and si2si_b are non-positivenonpositive */
      if ( (si1si_a != 0) && (si2si_b < (INT_MAX / si1si_a))) {
        /* handleHandle error condition */
      }
    } /* endEnd if si1si_a and si2si_b are non-positivenonpositive */
  } /* endEnd if si1si_a is non-positivenonpositive */

  result = si1si_a * si2;

...

Division

Division is between two operands of arithmetic type. Overflow can occur during two's-complement signed integer division when the dividend is equal to the minimum (negative) value for the signed integer type and the divisor is equal to — 1. Division operations are also susceptible to divide-by-zero errors. (See rule INT33-C. Ensure that division and modulo operations do not result in divide-by-zero errors.)

Noncompliant Code Example

This noncompliant code example can result in a signed integer overflow during the division of the signed operands sl1 and sl2 or in a divide-by-zero error. The IA-32 architecture, for example, requires that both conditions result in a fault, which can easily result in a denial-of-service attack.

signed long sl1, sl2, result;

/* Initialize sl1 and sl2 */

result = sl1 / sl2;

Compliant Solution

This compliant solution guarantees there is no possibility of signed overflow or divide-by-zero errors.

signed long sl1, sl2, result;

/* Initialize sl1 and sl2 */

if ( (sl2 == 0) || ( (sl1 == LONG_MIN) && (sl2 == -1) ) ) {
  /* handle error condition */
}
else {
  result = sl1 / sl2;
}

...

Modulo

The modulo operator provides the remainder when two operands of integer type are divided.

Noncompliant Code Example

This noncompliant code example can result in a divide-by-zero error. Furthermore, many hardware platforms implement modulo as part of the division operator, which can overflow. Overflow can occur during a modulo operation when the dividend is equal to the minimum (negative) value for the signed integer type and the divisor is equal to — 1. This occurs in spite of the fact that the result of such a modulo operation should theoretically be 0.

signed long sl1, sl2, result;

result = sl1 % sl2;

Implementation Details

On x86 platforms, the modulo operator for signed ints is implemented by the idiv instruction code, along with the divide operator. Since INT_MIN / -1 overflows, this code will throw a floating-point exception on INT_MIN % -1.

On MSVC++, taking the modulo of INT_MIN by -1 yields the value 0. On gcc/Linux, taking the modulo of INT_MIN by -1 produces a floating-point exception. However, on gcc versions 4.2.4 and newer, with optimization enabled, taking the modulo of INT_MIN by -1 yields the value 0.

Compliant Solution (Overflow Prevention)

This compliant solution tests the modulo operand to guarantee there is no possibility of a divide-by-zero error or an (internal) overflow error.

signed long sl1, sl2, result;

/* Initialize sl1 and sl2 */

if ( (sl2 == 0 ) || ( (sl1 == LONG_MIN) && (sl2 == -1) ) ) {
  /* handle error condition */
}
else {
  result = sl1 % sl2;
}

Compliant Solution (Absolute Value)

This compliant solution is based on the fact that both the division and modulo operators truncate towards zero, as specified in a footnote in paragraph 6.5.5 of the C99 standard. This guarantees that

i % j

and

i % -j

are always equivalent.

Furthermore, it guarantees that the minumum signed value modulo -1 yields 0.

signed long sl1, sl2, result;

/* Initialize sl1 and sl2 */

if (sl2 == 0) {
  /* handle error condition */
}
else {
  if ((sl2 < 0) && (sl2 != LONG_MIN)) {
    sl2 = -sl2;
  }
  result = sl1 % sl2;
}

...

Unary Negation

The unary negation operator takes an operand of arithmetic type. Overflow can occur during two's complement unary negation when the operand is equal to the minimum (negative) value for the signed integer type.

Noncompliant Code Example

This noncompliant code example can result in a signed integer overflow during the unary negation of the signed operand si1.

signed int si1, result;

/* Initialize si1 */

result = -si1;

Compliant Solution

This compliant solution tests the suspect negation operation to guarantee there is no possibility of signed overflow.

signed int si1, result;

/* Initialize si1 */

if (si1 == INT_MIN) {
  /* handle error condition */
}
else
  result = -si1;
}

...

Left-Shift Operator

The left-shift operator is between two operands of integer type.

Noncompliant Code Example

This noncompliant code example can result in signed integer overflow.

int si1, si2, sresult;

/* Initialize si1 and si2 */

sresult = si1 << si2;

Compliant Solution

This compliant solution eliminates the possibility of overflow resulting from a left-shift operation.

int si1, si2, sresult;

/* Initialize si1 and si2 */

if ( (si1 < 0) || (si2 < 0) ||
     (si2 >= sizeof(int)*CHAR_BIT) ||
     (si1 > (INT_MAX >> si2))
) {
  /* handle error condition */
}
else {
  sresult = si1 << si2;
}

This solution is also compliant with rule INT34-C. Do not shift a negative number of bits or more bits than exist in the operand.

Risk Assessment

Integer overflow can lead to buffer overflows and the execution of arbitrary code by an attacker.

Automated Detection

...

Tool

...

Version

...

Checker

...

Description

...

...

...

...

...

...

...

si_b;
}

Compliant Solution (GNU)

This compliant solution uses the GNU extension __builtin_smul_overflow, available with GCC, Clang, and ICC:

void func(signed int si_a, signed int si_b) {
  signed int result;
  if (__builtin_smul_overflow(si_a, si_b, &result)) {
    /* Handle error */
  }
}

Division

Division is between two operands of arithmetic type. Overflow can occur during two's complement signed integer division when the dividend is equal to the minimum (negative) value for the signed integer type and the divisor is equal to −1. Division operations are also susceptible to divide-by-zero errors. (See INT33-C. Ensure that division and remainder operations do not result in divide-by-zero errors.)

Noncompliant Code Example

This noncompliant code example prevents divide-by-zero errors in compliance with  INT33-C. Ensure that division and remainder operations do not result in divide-by-zero errors but does not prevent a signed integer overflow error in two's-complement. 

void func(signed long s_a, signed long s_b) {
  signed long result;
  if (s_b == 0) {
    /* Handle error */
  } else {
    result = s_a / s_b;
  }
  /* ... */
}

Implementation Details

On the x86-32 architecture, overflow results in a fault, which can be exploited as a  denial-of-service attack.

Compliant Solution

This compliant solution eliminates the possibility of divide-by-zero errors or signed overflow:

#include <limits.h>
 
void func(signed long s_a, signed long s_b) {
  signed long result;
  if ((s_b == 0) || ((s_a == LONG_MIN) && (s_b == -1))) {
    /* Handle error */
  } else {
    result = s_a / s_b;
  }
  /* ... */
}

Remainder

The remainder operator provides the remainder when two operands of integer type are divided. Because many platforms implement remainder and division in the same instruction, the remainder operator is also susceptible to arithmetic overflow and division by zero. (See INT33-C. Ensure that division and remainder operations do not result in divide-by-zero errors.)

Noncompliant Code Example

Many hardware architectures implement remainder as part of the division operator, which can overflow. Overflow can occur during a remainder operation when the dividend is equal to the minimum (negative) value for the signed integer type and the divisor is equal to −1. It occurs even though the result of such a remainder operation is mathematically 0. This noncompliant code example prevents divide-by-zero errors in compliance with INT33-C. Ensure that division and remainder operations do not result in divide-by-zero errors but does not prevent integer overflow:

void func(signed long s_a, signed long s_b) {
  signed long result;
  if (s_b == 0) {
    /* Handle error */
  } else {
    result = s_a % s_b;
  }
  /* ... */
}

Implementation Details

On x86-32 platforms, the remainder operator for signed integers is implemented by the idiv instruction code, along with the divide operator. Because LONG_MIN / −1 overflows, it results in a software exception with LONG_MIN % −1 as well.

Compliant Solution

This compliant solution also tests the remainder operands to guarantee there is no possibility of an overflow:

#include <limits.h>
 
void func(signed long s_a, signed long s_b) {
  signed long result;
  if ((s_b == 0 ) || ((s_a == LONG_MIN) && (s_b == -1))) {
    /* Handle error */
  } else {
    result = s_a % s_b;
  }  
  /* ... */
}

Left-Shift Operator

The left-shift operator takes two integer operands. The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. 

The C Standard, 6.5.8, paragraph 4 [ISO/IEC 9899:2024], states

If E1 has a signed type and nonnegative value, and E1 × 2E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined.

In almost every case, an attempt to shift by a negative number of bits or by more bits than exist in the operand indicates a logic error. These issues are covered by INT34-C. Do not shift an expression by a negative number of bits or by greater than or equal to the number of bits that exist in the operand.

Noncompliant Code Example

This noncompliant code example performs a left shift, after verifying that the number being shifted is not negative, and the number of bits to shift is valid.  The PRECISION() macro and popcount() function provide the correct precision for any integer type. (See INT35-C. Use correct integer precisions.) However, because this code does no overflow check, it can result in an unrepresentable value. 

#include <limits.h>
#include <stddef.h>
#include <inttypes.h>
 
extern size_t popcount(uintmax_t);
#define PRECISION(umax_value) popcount(umax_value) 

void func(signed long si_a, signed long si_b) {
  signed long result;
  if ((si_a < 0) || (si_b < 0) ||
      (si_b >= PRECISION(ULONG_MAX))) {
    /* Handle error */
  } else {
    result = si_a << si_b;
  } 
  /* ... */
}

Compliant Solution

This compliant solution eliminates the possibility of overflow resulting from a left-shift operation:

#include <limits.h>
#include <stddef.h>
#include <inttypes.h>
 
extern size_t popcount(uintmax_t);
#define PRECISION(umax_value) popcount(umax_value) 

void func(signed long si_a, signed long si_b) {
  signed long result;
  if ((si_a < 0) || (si_b < 0) ||
      (si_b >= PRECISION(ULONG_MAX)) ||
      (si_a > (LONG_MAX >> si_b))) {
    /* Handle error */
  } else {
    result = si_a << si_b;
  } 
  /* ... */
}

Unary Negation

The unary negation operator takes an operand of arithmetic type. Overflow can occur during two's complement unary negation when the operand is equal to the minimum (negative) value for the signed integer type.

Noncompliant Code Example

This noncompliant code example can result in a signed integer overflow during the unary negation of the signed operand s_a:

void func(signed long s_a) {
  signed long result = -s_a;
  /* ... */
}

Compliant Solution

This compliant solution tests the negation operation to guarantee there is no possibility of signed overflow:

#include <limits.h>
 
void func(signed long s_a) {
  signed long result;
  if (s_a == LONG_MIN) {
    /* Handle error */
  } else {
    result = -s_a;
  }
  /* ... */
}

Risk Assessment

Integer overflow can lead to buffer overflows and the execution of arbitrary code by an attacker.

Automated Detection

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

Key here (explains table format and definitions)

CERT-CWE Mapping Notes

Key here for mapping notes

CWE-20 and INT32-C

See CWE-20 and ERR34-C

CWE-680 and INT32-C

Intersection( INT32-C, MEM35-C) = Ø

Intersection( CWE-680, INT32-C) =

• Signed integer overflows that lead to buffer overflows

CWE-680 - INT32-C =

• Unsigned integer overflows that lead to buffer overflows

INT32-C – CWE-680 =

• Signed integer overflows that do not lead to buffer overflows

CWE-191 and INT32-C

Union( CWE-190, CWE-191) = Union( INT30-C, INT32-C)

Intersection( INT30-C, INT32-C) == Ø

Intersection(CWE-191, INT32-C) =

• Underflow of signed integer operation

CWE-191 – INT32-C =

• Underflow of unsigned integer operation

INT32-C – CWE-191 =

• Overflow of signed integer operation

CWE-190 and INT32-C

Union( CWE-190, CWE-191) = Union( INT30-C, INT32-C)

Intersection( INT30-C, INT32-C) == Ø

Intersection(CWE-190, INT32-C) =

• Overflow (wraparound) of signed integer operation

CWE-190 – INT32-C =

• Overflow of unsigned integer operation

INT32-C – CWE-190 =

• Underflow of signed integer operation

Bibliography

...

Image Added Image Added Image Added

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

CERT C++ Secure Coding Standard: INT32-CPP. Ensure that operations on signed integers do not result in overflow

The CERT Oracle Secure Coding Standard for Java: INT00-J. Perform explicit range checking to avoid integer overflow

ISO/IEC 9899:1999 Section 6.5, "Expressions," and Section 7.10, "Sizes of integer types <limits.h>"

ISO/IEC TR 24772 "XYY Wrap-around Error"

MITRE CWE: CWE-129, "Unchecked Array Indexing"

MITRE CWE: CWE-190, "Integer Overflow (Wrap or Wraparound)"

Bibliography

\[[Dowd 2006|AA. Bibliography#Dowd 06]\] Chapter 6, "C Language Issues" (Arithmetic Boundary Conditions, pp. 211-223)
\[[Seacord 2005|AA. Bibliography#Seacord 05]\] Chapter 5, "Integers"
\[[Viega 2005|AA. Bibliography#Viega 05]\] Section 5.2.7, "Integer overflow"
\[[VU#551436|AA. Bibliography#VU551436]\]
\[[Warren 2002|AA. Bibliography#Warren 02]\] Chapter 2, "Basics"

Image Removed      04. Integers (INT)      INT33-C. Ensure that division and modulo operations do not result in divide-by-zero errors