You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 208 Next »

Signed integer overflow is undefined behavior (see undefined behavior 36 in Annex J of the C Standard). This means that implementations have a great deal of latitude in how they deal with signed integer overflow.

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

Other implementations may cause a hardware trap (also called 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.

Still other implementations may simply assume that signed integers never overflow and may 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 may emit efficient code on the basis of that determination, while the same implementation may avoid making that assumption in another function when the variable is a global object.

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

  • 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)
  • As an argument to a memory allocation function
  • In security-critical code

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 can result in overflow:

Operator

Overflow

Operator

Overflow

Operator

Overflow

Operator

Overflow

+

Yes

-=

Yes

<<

Yes

<

No

-

Yes

*=

Yes

>>

No

>

No

*

Yes

/=

Yes

&

No

>=

No

/

Yes

%=

Yes

|

No

<=

No

%

Yes

<<=

Yes

^

No

==

No

++

Yes

>>=

No

~

No

!=

No

--

Yes

&=

No

!

No

&&

No

=

No

|=

No

un +

No

||

No

+=

Yes

^=

No

un -

Yes

?:

No

The following sections examine specific operations that are susceptible to integer overflow. When operating on small integer types (smaller 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. Programmers should understand integer conversion rules before trying to implement secure arithmetic operations. (See INT02-C. Understand integer conversion rules.)

Addition

Addition is between two operands of arithmetic type or between a pointer to an object type and an integer 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 may result in a signed integer overflow during the addition of the signed operands si_a and si_b. If this behavior is unanticipated, it can lead to an exploitable vulnerability.

void func(signed int si_a, signed int si_b) {
  signed int sum = si_a + si_b;

  /* ... */
}

Compliant Solution

This compliant solution tests the suspect addition operation to ensure no overflow occurs 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)))) {
    /* Handle error */
  } else {
    sum = si_a + si_b;
  }
  /* ... */
}

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. 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. 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.

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, regardless of representation:

#include <limits.h>
 
void func(signed int si_a, signed int si_b) {
  signed int diff;
  if ((si_b > 0 && si_a < INT_MIN + si_b) ||
      (si_b < 0 && si_a > INT_MAX + si_b)) {
    /* Handle error */
  } else {
    diff = si_a - si_b;
  }

  /* ... */
}

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 si_a and si_b. 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.

void func(signed int si_a, signed int si_b) {
  signed int result = si_a * si_b;

  /* ... */
}

Compliant Solution

This compliant solution guarantees there is no possibility of signed overflow on systems where long long is at least twice the width of int:

#include <stddef.h>
#include <assert.h>
#include <limits.h>
#include <inttypes.h>
 
size_t popcount(uintmax_t num) {
  size_t width = 0;
  while (num != 0) {
    if (num % 2 == 1) {
      width++;
    }
    num >>= 1;
  }
  return width;
}
#define UWIDTH(umax_value) popcount(umax_value)
  
void func(signed int si_a, signed int si_b) {
  signed int result;
  signed long long tmp;
  assert(UWIDTH(ULLONG_MAX) >=
         2 * UWIDTH(UINT_MAX));
  tmp = (signed long long)si_a * (signed long long)si_b;
 
  /*
   * If the product cannot be represented as a 32-bit integer,
   * handle as an error condition.
   */
  if ((tmp > INT_MAX) || (tmp < INT_MIN)) {
    /* Handle error */
  } else {
    result = (int)tmp;
  }
  /* ... */
}

The assertion fails if long long has less than twice the width of int. The purpose of the UWIDTH() macro and the function popcount() is explained in INT19-C. Correctly compute integer widths.

On systems where this assertion would fail, this compliant solution may be used to ensure signed overflow does not occur:

#include <limits.h>
 
void func(signed int si_a, signed int si_b) {
  signed int result;  
  if (si_a > 0) {  /* si_a is positive */
    if (si_b > 0) {  /* si_a and si_b are positive */
      if (si_a > (INT_MAX / si_b)) {
        /* Handle error */
      }
    } else { /* si_a positive, si_b nonpositive */
      if (si_b < (INT_MIN / si_a)) {
        /* Handle error */
      }
    } /* si_a positive, si_b nonpositive */
  } else { /* si_a is nonpositive */
    if (si_b > 0) { /* si_a is nonpositive, si_b is positive */
      if (si_a < (INT_MIN / si_b)) {
        /* Handle error */
      }
    } else { /* si_a and si_b are nonpositive */
      if ( (si_a != 0) && (si_b < (INT_MAX / si_a))) {
        /* Handle error */
      }
    } /* End if si_a and si_b are nonpositive */
  } /* End if si_a is nonpositive */

  result = si_a * si_b;
}

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 modulo operations do not result in divide-by-zero errors.)


Modulo

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

Left-Shift Operator

The left-shift operator takes two operands of integer type. For examples of usage of the left-shift operator, see INT34-C. Do not shift a negative number of bits or more bits than exist in the operand.

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 suspect 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;
  }
  /* ... */
}


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. However, 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. 

This section includes an example for the addition of atomic integer types only. For other operations, tests similar to the precondition tests for two’s complement integers used for nonatomic integer types can be used.

Noncompliant Code Example

This noncompliant code example using atomic integers can result in unexpected signed integer overflow:

#include <stdatomic.h>
 
atomic_int i;

void func(int si_a) {
  atomic_init(&i, 42); 
  atomic_fetch_add(&i, si_a);

  /* ... */
}

Compliant Solution

This compliant solution tests the operands to guarantee there is no possibility of signed overflow. It loads the value stored in the atomic integer and tests for possible overflow before performing the addition. However, this code contains a race condition where i can be modified after the load, but prior to the atomic store. This solution is only compliant if i is guaranteed to only be access by a single thread. See CON43-C. Do not assume that a group of calls to independently atomic methods is atomic for more information.

#include <limits.h>
#include <stdatomic.h>
 
atomic_int i;

void func(int si_a) {
  int si_b = atomic_load(&i);

  if (((si_b > 0) && (si_a > (INT_MAX - si_b))) ||
      ((si_b < 0) && (si_a < (INT_MIN - si_b)))) {
    /* Handle error */
  } else {
    atomic_store(&i, si_a + si_b);
  }

  /* ... */
}

Risk Assessment

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

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

INT32-C

High

Likely

High

P9

L2

Automated Detection

Tool

Version

Checker

Description

Coverity6.5TAINTED_STATICFully Implemented

Fortify SCA

5.0

 

Can detect violations of this rule with CERT C Rule Pack. Specifically, it checks to ensure that the operand of a unary negation is compared to the type's minimum value immediately before the operation

LDRA tool suite

9.7.1

43 D
493 S
494 S

Partially implemented
PRQA QA-C
Unable to render {include} The included page could not be found.

0278
0296
0297
2800

Fully implemented

Related Vulnerabilities

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

Related Guidelines

Bibliography

[Dowd 2006]Chapter 6, "C Language Issues" ("Arithmetic Boundary Conditions," pp. 211–223)
[ISO/IEC 9899:2011]Subclause 6.5.5, "Multiplicative Operators"
[Seacord 2013]Chapter 5, "Integer Security"
[Viega 2005]Section 5.2.7, "Integer Overflow"
[VU#551436] 
[Warren 2002]Chapter 2, "Basics"

 


 

  • No labels