...
Integer overflow is undefined behavior, so a compiled program can do anything, including going off to play the Game of Life. Furthermore, a compiler may perform optimizations that assume an overflow will never occur, which can easily yield unexpected results. Compilers can optimize away if statements that check whether an overflow occurred. See guideline MSC15-C. Do not depend on undefined behavior for an example.
| Wiki Markup |
|---|
Verifiably in-range operations are often preferable to treating out-of-range values as an error condition because the handling of these errors has been repeatedly shown to cause denial-of-service problems in actual applications. The quintessential example of this is the failure of the Ariane 5 launcher, which occurred because of an improperly handled conversion error that resulted in the processor being shut down \[[Lions 961996|AA. Bibliography#Lions 96]\]. |
...
| Wiki Markup |
|---|
In modwrap semantics (also called _modulo_ arithmetic), integer values "wrap round." That is, adding one to {{MAX}} produces {{MIN}}. This is the defined behavior for unsigned integers in the C Standard \[[ISO/IEC 9899:1999|AA. Bibliography#ISO/IEC 9899-1999]\] (see, Section 6.2.5, "Types," paragraph 9), and is frequently the behavior of signed integers, as well. However, it is more sensible in many applications to use saturation semantics instead of modwrap semantics. For example, in the computation of a size (using unsigned integers), it is often better for the size to stay at the maximum value in the event of overflow rather than suddenly becoming a very small value. |
...
| Wiki Markup |
|---|
Another tool for avoiding integer overflow is to use only half the range of signed integers. For example, when using an {{int}}, use only the range \[{{INT_MIN}}/2, {{INT_MAX}}/2\]. This has been a trick of the trade in Fortran for some time, and now that optimizing C compilers are becoming more sophisticated, it can be valuable in C. |
...
| Wiki Markup |
|---|
Now, if the user types {{a < b}}, there is often an implicit subtraction happening. On a machine without condition codes, the compiler may simply issue a subtract instruction and check whether the result is negative. This is allowed, because the compiler is allowed to assume there is no overflow. If all explicitly user-generated values are kept in the range {{\[INT_MIN/2, INT_MAX/2\]}}, then comparisons will always work even if the compiler performs this optimization on such hardware. |
...
In this noncompliant example, i + 1 will overflow on a 16-bit machine. The C standard allows signed integers to overflow and produce incorrect results. Compilers can take advantage of this to produce faster code by assuming an overflow will not occur. As a result, the if statement that is intended to catch an overflow might be optimized away.
...
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
INT08-C | medium | probable | high | P4 | L3 |
Automated Detection
...
Tool | Version | Checker | Description |
|---|---|---|---|
|
...
|
|
| ||||||||
|
|
|
|
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Other Languages
Related Guidelines
This rule appears in the C++ Secure Coding Standard as : INT08-CPP. Verify that all integer values are in range.
Bibliography
| Wiki Markup |
|---|
\[[ISO/IEC PDTR 24772|AA. Bibliography#ISO/IEC PDTR 24772]\] "FLC Numeric Conversion Errors" \[[Lions 961996|AA. Bibliography#Lions 96]\] |
...