I have run HP fortify scan on our code which uses Boos libraries for checking security vulnerabilities. During the scan I got issues reported in below two files.

1. compressed_pair.hpp
2. next_prior.hpp

The issue reported as below.
1. compressed_pair.hpp  (In line 154)

LINE 153:          compressed_pair_imp(first_param_type x, second_param_type y)
LINE 154:          : first_type(x), second_(y) {}

Abstract: The program reads data from just outside the bounds of allocated memory.

Explanation:

Buffer overflow is probably the best known form of software security vulnerability. Most software developers know what a buffer overflow vulnerability is, but buffer overflow attacks against both legacy and newly-developed applications are still quite common. Part of the problem is due to the wide variety of ways buffer overflows can occur, and part is due to the error-prone techniques often used to prevent them.

In a classic buffer overflow exploit, the attacker sends data to a program, which it stores in an undersized stack buffer. The result is that information on the call stack is overwritten, including the function's return pointer. The data sets the value of the return pointer so that when the function returns, it transfers control to malicious code contained in the attacker's data.

2. next_prior.hpp  (In line 30)

LINE 29:           template <class T>
LINE 30            inline T next(T x) { return ++x; }

Abstract: The function next() in next_prior.hpp reads data from just outside the bounds of ~tp~1 on line 30.


Explanation:

Buffer overflow is probably the best known form of software security vulnerability. Most software developers know what a buffer overflow vulnerability is, but buffer overflow attacks against both legacy and newly-developed applications are still quite common. Part of the problem is due to the wide variety of ways buffer overflows can occur, and part is due to the error-prone techniques often used to prevent them.

In a classic buffer overflow exploit, the attacker sends data to a program, which it stores in an undersized stack buffer. The result is that information on the call stack is overwritten, including the function's return pointer. The data sets the value of the return pointer so that when the function returns, it transfers control to malicious code contained in the attacker's data.

Question is: Is this really an issue with the code? or boost has taken care of this out of bound in its code?