Signed integer overflow is undefined behavior (see undefined behavior 33 36 in Annex J .2 of C99C11). This means that implementations have a great deal of latitude in how they deal with signed integer overflow.
...
Other implementations may cause a hardware trap (also referred to as 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.
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 GNU GCC invoked without either the -fwrapv or the -ftrapv option.
...
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 and are used in any of the following ways:
...
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. Make sure you understand integer conversion rules before trying to implement secure arithmetic operations. (See recommendation INT02-C. Understand integer conversion rules.)
...
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.
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
int si1, si2, sum; /* Initialize si1 and si2 */ sum = si1 + si2; |
Compliant Solution (
...
Precondition Test, Two's Complement)
This compliant solution performs a pre-condition precondition test of the operands of the addition to ensure no overflow occurs, assuming two's complement representation.
...
This compliant solution works only on architectures that use two's complement representation. While Although 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 postcondition test, especially on RISC CPUs.
...
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.
...
This compliant solution only works on architectures that use two's complement representation. While Although 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.)
...
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.
...
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−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.)
...
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 — 1to−1. This occurs in spite of the fact occurs despite that the result of such a modulo operation should theoretically be 0.
...
On x86 platforms, the modulo operator for signed ints integers 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 −1 yields the value 0. On gcc/Linux, taking the modulo of INT_MIN by -1 −1 produces a floating-point exception. However, on gcc on gcc versions 4.2.4 and newer, with optimization enabled, taking the modulo of INT_MIN by -1 −1 yields the value 0.
Compliant Solution (Overflow Prevention)
...
This compliant solution is based on the fact that both the division and modulo operators truncate towards toward zero, as specified in a footnote in paragraph Section 6.5.5 of the C99 standard, footnote 105, of the C standard [ISO/IEC 9899:2011]. This guarantees that
| Code Block |
|---|
i % j |
...
Furthermore, it guarantees that the minumum signed value modulo -1 −1 yields 0.
| Code Block | ||||
|---|---|---|---|---|
| ||||
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;
}
|
...
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.
...
The C Standard [ISO/IEC 9899:2011] defines the behavior of arithmetic on atomic signed integer types to use two's complement representation with silent wrap-around wraparound on overflow; there are no undefined results. However, while 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 only includes an example for the addition of atomic integer types only. For other operations, you can use tests similar to the precondition tests for two’s complement integers used for non-atomic nonatomic integer types.
Noncompliant Code Example
...
Tool | Version | Checker | Description | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Section |
| |||||||||||||
| Section | 43 D | |||||||||||||
| Section | Partially | Implementedimplemented. | ||||||||||||
| Section | ||||||||||||||
Fortify SCA | ||||||||||||||
| Section | V. 5.0 | |||||||||||||
| Section | 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. |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
...
The CERT Oracle Secure Coding Standard for Java: INT00-J. Perform explicit range checking to avoid integer overflow
ISO/IEC 9899:19992011 Section 6.5, "Expressions," and Section 7.10, "Sizes of integer types <limits.h>"
ISO/IEC TR 17961 (Draft) Overflowing signed integers [intoflow]
ISO/IEC TR 24772 "XYY Wrap-around Error"
...