- Checking for overflow of integer addition needs to be done with - care, because automatic type promotion can prevent the check - from working correctly. -
-- Use an explicit cast to make sure that the result of the addition is - not implicitly converted to a larger type. -
-- On a typical architecture where short is 16 bits - and int is 32 bits, the operands of the addition are - automatically promoted to int, so it cannot overflow - and the result of the comparison is always false. -
-- The code below implements the check correctly, by using an - explicit cast to make sure that the result of the addition - is unsigned short. -
-
+Checking for overflow of integer addition needs to be done with
+care, because automatic type promotion can prevent the check
+from working as intended, with the same value (true
+or false) always being returned.
+
+Use an explicit cast to make sure that the result of the addition is +not implicitly converted to a larger type. +
+
+On a typical architecture where short is 16 bits
+and int is 32 bits, the operands of the addition are
+automatically promoted to int, so it cannot overflow
+and the result of the comparison is always false.
+
+The code below implements the check correctly, by using an
+explicit cast to make sure that the result of the addition
+is unsigned short (which may overflow, in which case
+the comparison would evaluate to true).
+
+When checking for integer overflow, you may often write tests like
+a + b < a. This works fine if a or
+b are unsigned integers, since any overflow in the addition
+will cause the value to simply "wrap around." However, using
+signed integers is problematic because signed overflow has undefined
+behavior according to the C and C++ standards. If the addition overflows
+and has an undefined result, the comparison will likewise be undefined;
+it may produce an unintended result, or may be deleted entirely by an
+optimizing compiler.
+
+Solutions to this problem can be thought of as falling into one of two +categories: (1) rewrite the signed expression so that overflow cannot occur +but the signedness remains, or (2) rewrite (or cast) the signed expression +into unsigned form. +
+ ++Below we list examples of expressions where signed overflow may +occur, along with proposed solutions. The list should not be +considered exhaustive. +
+ +
+Given unsigned short i, delta and i + delta < i,
+it is possible to rewrite it as (unsigned short)(i + delta) < i.
+Note that i + deltadoes not actually overflow, due to int promotion
+
+Given unsigned short i, delta and i + delta < i,
+it is also possible to rewrite it as USHORT_MAX - delta. It must be true
+that delta > 0 and the limits.h or climits
+header has been included.
+
+Given int i, delta and i + delta < i,
+it is possible to rewrite it as INT_MAX - delta. It must be true
+that delta > 0 and the limits.h or climits
+header has been included.
+
+Given int i, delta and i + delta < i,
+it is also possible to rewrite it as (unsigned)i + delta < i.
+Note that program semantics are affected by this change.
+
+Given int i, delta and i + delta < i,
+it is also possible to rewrite it as unsigned int i, delta and
+i + delta < i. Note that program semantics are
+affected by this change.
+
+In the following example, even though delta has been declared
+unsigned short, C/C++ type promotion rules require that its
+type is promoted to the larger type used in the addition and comparison,
+namely a signed int. Addition is performed on
+signed integers, and may have undefined behavior if an overflow occurs.
+As a result, the entire (comparison) expression may also have an undefined
+result.
+
+The following example builds upon the previous one. Instead of
+performing an addition (which could overflow), we have re-framed the
+solution so that a subtraction is used instead. Since delta
+is promoted to a signed int and INT_MAX denotes
+the largest possible positive value for an signed int,
+the expression INT_MAX - delta can never be less than zero
+or more than INT_MAX. Hence, any overflow and underflow
+are avoided.
+
+In the following example, even though both n and delta
+have been declared unsigned short, both are promoted to
+signed int prior to addition. Because we started out with the
+narrower short type, the addition is guaranteed not to overflow
+and is therefore defined. But the fact that n1 + delta never
+overflows means that the condition n1 + delta < n1 will never
+hold true, which likely is not what the programmer intended. (see also the
+cpp/bad-addition-overflow-check query).
+
+The next example provides a solution to the previous one. Even though
+i + delta does not overflow, casting it to an
+unsigned short truncates the addition modulo 2^16,
+so that unsigned short "wrap around" may now be observed.
+Furthermore, since the left-hand side is now of type unsigned short,
+the right-hand side does not need to be promoted to a signed int.
+
+Data received over a network connection may be received in a different byte order than
+the byte order used by the local host, making the data difficult to process. To address this,
+data received over the wire is usually converted to host byte order by a call to a network-to-host
+byte order function, such as ntohl.
+
+The use of a network-to-host byte order function is therefore a good indicator that the returned +value is unvalidated data retrieved from the network, and should not be used without further +validation. In particular, the returned value should not be used as an array index or array length +value without validation, as this could result in a buffer overflow vulnerability. +
++Validate data returned by network-to-host byte order functions before use and especially before +using the value as an array index or bound. +
+In the example below, network data is retrieved and passed to ntohl to convert
+it to host byte order. The data is then used as an index in an array access expression. However,
+there is no validation that the data returned by ntohl is within the bounds of the array,
+which could lead to reading outside the bounds of the buffer.
+
In the corrected example, the returned data is validated against the known size of the buffer, +before being used as an array index.
+
+When checking for integer overflow, you may often write tests like
+p + i < p. This works fine if p and
+i are unsigned integers, since any overflow in the addition
+will cause the value to simply "wrap around." However, using this pattern when
+p is a pointer is problematic because pointer overflow has
+undefined behavior according to the C and C++ standards. If the addition
+overflows and has an undefined result, the comparison will likewise be
+undefined; it may produce an unintended result, or may be deleted entirely by an
+optimizing compiler.
+
+To check whether an index i is less than the length of an array,
+simply compare these two numbers as unsigned integers: i < ARRAY_LENGTH.
+If the length of the array is defined as the difference between two pointers
+ptr and p_end, write i < p_end - ptr.
+If i is signed, cast it to unsigned
+in order to guard against negative i. For example, write
+(size_t)i < p_end - ptr.
+
+An invalid check for pointer overflow is most often seen as part of checking
+whether a number a is too large by checking first if adding the
+number to ptr goes past the end of an allocation and then
+checking if adding it to ptr creates a pointer so large that it
+overflows and wraps around.
+
+In both of these checks, the operations are performed in the wrong order.
+First, an expression that may cause undefined behavior is evaluated
+(ptr + i), and then the result is checked for being in range.
+But once undefined behavior has happened in the pointer addition, it cannot
+be recovered from: it's too late to perform the range check after a possible
+pointer overflow.
+
+While it's not the subject of this query, the expression ptr + i <
+ptr_end is also an invalid range check. It's undefined behavor in
+C/C++ to create a pointer that points more than one past the end of an
+allocation.
+
+The next example shows how to portably check whether an unsigned number is outside the
+range of an allocation between ptr and ptr_end.
+
Using the TLS or SSLv23 protocol from the boost::asio library, but not disabling deprecated protocols may expose the software to known vulnerabilities or permit weak encryption algorithms to be used. Disabling the minimum-recommended protocols is also flagged.
+Using boost::asio library but specifying a deprecated hardcoded protocol.
+Using a deprecated hardcoded protocol instead of negotiting would lock your application to a protocol that has known vulnerabilities or weaknesses.
+A common pattern is to initialize a local variable by calling another function (an +"initialization" function) with the address of the local variable as a pointer argument. That +function is then responsible for writing to the memory location referenced by the pointer.
+ +In some cases, the called function may not always write to the memory pointed to by the +pointer argument. In such cases, the function will typically return a "status" code, informing the +caller as to whether the initialization succeeded or not. If the caller does not check the status +code before reading the local variable, it may read unitialized memory, which can result in +unexpected behavior.
+ +When using a initialization function that does not guarantee to initialize the memory pointed to +by the passed pointer, and returns a status code to indicate whether such initialization occurred, +the status code should be checked before reading from the local variable.
+ +In this hypothetical example we have code for managing a series of devices. The code
+includes a DeviceConfig struct that can represent properties about each device.
+The initDeviceConfig function can be called to initialize one of these structures, by
+providing a "device number", which can be used to look up the appropriate properties in some data
+store. If an invalid device number is provided, the function returns a status code of
+-1, and does not initialize the provided pointer.
In the first code sample below, the notify function calls the
+initDeviceConfig function with a pointer to the local variable config,
+which is then subsequently accessed to fetch properties of the device. However, the code does not
+check the return value from the function call to initDeviceConfig. If the
+device number passed to the notify function was invalid, the
+initDeviceConfig function will leave the config variable uninitialized,
+which will result in the notify function accessing uninitialized memory.
To fix this, the code needs to check that the return value of the call to
+initDeviceConfig is zero. If that is true, then the calling code can safely assume
+that the local variable has been initialized.