Page History

Do not add or subtract an integer to a pointer if the resulting value does not refer to an element within the array (or to the nonexistent element just after the last element of the array). According to the C++ Standard ISO/IEC 14882-2003, section 5.7Expressions that have an integral type can be added to or subtracted from a pointer, resulting in a value of the pointer type. If the resulting pointer would not be a valid member of the container, or one past the last element of the container, the behavior of the additive operator is undefined. The C++ Standard, [expr.add], paragraph 5 [ISO/IEC 14882-2014], states, in part:

If both the pointer operand and the result point to elements of the same array object, or one past the past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined.

If the pointer resulting from the addition (or subtraction) is outside of the bounds of the array, an overflow has occurred and the result is undefined.

is undefined.

Since iterators are a generalization of pointers, the same constraints apply to additive operators with random access iterators. Specifically, the Likewise, adding or subtracting an integer to an iterator if the resulting value does not refer to an element within the container (or to the nonexistent element just after the last element in the container). The C++ Standard, section 24.1 [iterator.requirements.general], paragraph 5, saysstates:

Just as a regular pointer to an array guarantees that there is a pointer value pointing past the last element of element of the array, so for any iterator type there is an iterator value that points past the last element of a corresponding containera corresponding sequence. These values are called past-the-end values. Values of an iterator i for  for which the expression the expression *i is  is defined are called dereferenceable. The library never assumes that past-the-end values are dereferenceableare dereferenceable.

Do not allow an expression of integral type to add to or subtract from a pointer or random access iterator when the resulting value would overflow the bounds of the container.

Noncompliant Code Example (

...

std::vector)

In this noncompliant code example, a pointer is set to reference the start of an array. Array elements are accessed sequentially within the for loop. The array pointer ip is incremented on each iteration.random access iterator from a std::vector is used in an additive expression, but the resulting value could be outside of the bounds of the container, and not a past-the-end value.

int ar[20];

for (int *ip = &ar[0]; ip < &ar[21]; ip++) {
  *ip = 0;
}

C++2003 guarantees that it is permissible to use the address of ar[20] even though no such element exists. However, in this noncompliant code example, the bound of the array is incorrectly specified, and consequently, the reference to &ar[21] constitutes undefined behavior. On the final iteration of the loop, the expression ip++ (which adds 1 to ip) will also overflow.

This code also suffers from using "magic numbers," described in DCL06-CPP. Use meaningful symbolic constants to represent literal values in program logic. When replacing the numbers with constants, a developer is likely to catch the invalid array bounds in the for statement.

Compliant Solution (Arrays)

#include <vector>
 
void f(const std::vector<int> &C) {
  for (auto I = C.begin(), E = I + 20; I != E; ++I) {
    std::cout << *I << std::endl;
  }
}

Compliant Solution (std::vector)

This compliant solution assumes that the programmer's intention was to process up to twenty items in the container. Instead of assuming all containers will have twenty or more elements, the size of the container is used to determine the upper bound on the additionThis compliant solution fixes the problem from the previous noncompliant code example by using the common idiom sizeof(ar)/sizeof(ar[0]) to determine the actual number of elements in the array. This idiom works only when the definition of the array is visible (see CTR01-CPP. Do not apply the sizeof operator to a pointer when taking the size of an array).

int ar[20];#include <algorithm>
#include <vector>

forvoid f(int *ip = &ar[0]; ip < &ar[sizeof(ar)/sizeof(ar[0])]; ip++const std::vector<int> &C) {
   *ipconst std::vector<int>::size_type MaxSize = 0;
}

C++2003 guarantees that it is permissible to use the address of ar[sizeof(ar)/sizeof(ar[0])] even though no such element exists. This allows you to use it for checks in loops like the one in this Compliant Solution. The guarantee extends only to one element beyond the end of an array and no further Banahan 03.

Noncompliant Code Example (Vectors)

In this noncompliant code example, an iterator is set to reference the beginning of a vector. Vector elements are accessed sequentially within the for loop. The iterator ip is incremented on each iteration.

vector<int> ar( 20, 0);
vector<int>::iterator ip = ar.begin();
for (int i = 1; i <= 22; i++) {
  *ip++ = 1;
}

C++2003 guarantees that it is permissible for the iterator to refer to the 21st element of the vector, even though the vector has only 20 elements. However, this code tries to dereference the 21st element, which is undefined. Furthermore, it also tries to increment the iterator to refer to the 22nd element of the vector, which is also undefined. On the final iteration of the loop, the expression ip++ (which increments ip) will also overflow.

20;
  for (auto I = C.begin(), E = I + std::min(MaxSize, C.size()); I != E; ++I) {
    // ...
  }
}

This compliant solution also uses a named constant value in compliance with This code also suffers from using "magic numbers," described in DCL06-CPP. Use meaningful symbolic constants to represent literal values in program logic. When replacing the numbers with constants, a developer is likely to catch the invalid bounds in the for statement.

...

This compliant solution fixes the problem from the previous noncompliant code example by using the ranges ar.begin() and ar.end() to determine how many iterations should be executed.

vector<int> ar( 20, 0);
for (vector<int>::iterator ip = ar.begin(); ip < ar.end(); ip++) {
  *ip++ = 1;
}

Since the iterator::end() method returns an iterator pointing to one element past the end of the vector, it functions as a useful loop terminator.

Non-Compliant Code Example (Linear Address Space)

Pointer arithmetic can result in undefined behavior if the pointer operand and the resulting pointer do not refer to the same array object (or one past the last element of the array object). Compiler implementations are provided broad latitude by the standard in how to deal with undefined behavior (see MSC15-CPP. Do not depend on undefined behavior) including ignoring the situation completely with unpredictable results.

In this noncompliant code example, the programmer an attempt is trying made to determine if a pointer added to a length will wrap around the end of memory.addition will cause a linear address space wraparound:

char *buf;
size_t len = 1 << 30;

/* Check for overflow */
if (buf + len < buf) {
  len = -(size_t)buf-1;
}

This code resembles the test for wraparound from the sprint() function as implemented for the Plan 9 operating system. If buf + len < buf evaluates to true, len is assigned the remaining space, minus 1 one byte. However, because the expression buf + len < buf constitutes undefined behavior, compilers can assume this condition will never occur and optimize out away the entire conditional statement.

Implementation Details

In gcc GCC versions 4.2 and later, for example, code that performs checks for wrapping that depend on undefined behavior (such as the code in this noncompliant code example) are optimized away; no object code to perform the check appears in the resulting executable program [VU#162289]. This is of special concern because it often results in the silent elimination of code that was inserted to provide a safety or security check. For gcc version GCC 4.2.4 and later, this optimization may be disabled for with the -fno-strict-overflow option.

Compliant Solution (Linear Address Space)

In this compliant solution, both references to buf are cast to sizestd::uintptr_t. Because {[sizestd::uinptr_t}} is  is an unsigned integral type of sufficient size to store a pointer value, C++ 2003 guarantees that it has modulo behavior.

char *buf;
size_t len = 1 << 30;

/* Check for overflow */
if ((size_t)buf+reinterpret_cast<std::uintptr_t>(buf) + len < (size_t)bufreinterpret_cast<std::uintptr_t>(buf)) {
  len = -(size_t)buf-1;
}

This compliant solution works on architectures that provide a linear address space. Some word-oriented machines are likely to produce a word address with the high-order bits used as a byte selector, in which case this solution will fail. Consequently, this is not a portable solution.

Non-Compliant Code Example (Pointer Addition)

Another interesting case is shown in this noncompliant code example. The expression buf + n may wrap for large values of n, resulting in undefined behavior.

int process_array(char *buf, size_t n) {
  return buf + n < buf + 100;
}

This is an example of how optimization may actually help improve security. When compiled using GCC 4.3.0 with the -O2 option, for example, the expression buf + n < buf + 100 is optimized to n < 100, eliminating the possibility of wrapping. This code example is still noncompliant, because it is not safe to rely on compiler optimizations for security.

Compliant Solution (Pointer Addition)

In this compliant solution, the "optimization" is performed by hand.

...

...

...

int process_array(char *buf, size_t n) {
  return n < 100;
}

Risk Assessment

If adding or subtracting an integer to a pointer results in a reference to an element outside the array or one past the last element of the array object, the behavior is undefined, but frequently leads to a buffer overflow or buffer underrun which can often be exploited to run arbitrary code. Iterators and STL containers exhibit the same behavior and caveats as pointers and arrays.

Automated Detection

...

Compass/ROSE could detect violations of this rule. At least it can catch all of the NCCE's.

...

...

Coverity Code Advisor version 7.5 can detect violations of this rule.

Klocwork Version 8.0.4.16 can detect violations of this rule with the ABR checker.

PRQA QA-C++

Tool	Version	Checker	Description
Include Page
	PRQA QA-C++_v	PRQA QA-C++_v	2930, 2931, 2932, 2933, 2934, 2950, 2951, 2952, 2953

Related Vulnerabilities

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

Other Languages

This rule appears in the C Secure Coding Standard as VOID Do not add or subtract an integer to a pointer if the resulting value does not refer to a valid array element.

...

Related Guidelines

Bibliography

...

...

...

...

[ISO/IEC 14882-2003] Section 18.7
[MITRE 07] CWE ID 129, "Unchecked Array Indexing"
[VU#162289]Image Removed      06Image Added      006. Containers (CTR)      CTR39-CPP. Do not use pointer arithmetic on polymorphic objects