Page History

...

1. If both operands have the same type, no further conversion is needed.
2. If both operands are of the same integer type (signed or unsigned), the operand with the type of lesser integer conversion rank is converted to the type of the operand with greater rank.
3. If the operand that has unsigned integer type has rank greater than or equal to the rank of the type of the other operand, the operand with signed integer type is converted to the type of the operand with unsigned integer type.
4. If the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, the operand with unsigned integer type is converted to the type of the operand with signed integer type.
5. Otherwise, both operands are converted to the unsigned integer type corresponding to the type of the operand with signed integer type. Specific operations can add to or modify the semantics of the usual arithmetic operations.

Example

In the following example, assume the code is compiled using an implementation with 8-bit char, 32-bit int, and 64-bit long long:

...

Noncompliant Code Example

This noncompliant code noncompliant code example demonstrates how performing bitwise operations on integer types smaller than int may have unexpected results:

...

In this example, a bitwise complement of port is first computed and then shifted 4 bits to the right. If both of these operations are performed on an 8-bit unsigned integer, then result_8 will have the value 0x0a. However, port is first promoted to a signed int, with the following results (on a typical architecture where type int is 32 bits wide):

Compliant Solution

In this compliant solution, the bitwise complement of port is converted back to 8 bits. Consequently, result_8 is assigned the expected value of 0x0aU.

uint8_t port = 0x5a;
uint8_t result_8 = (uint8_t) (~port) >> 4;

Noncompliant Code Example

In this example, a character is iterated from 0 to CHAR_MAX. However, on a platform where char is signed (such as 32-bit x86), max  is set to 0x80  while i  increments from 0x79  to {{0xffffff80} (aka -127):

#include <limits.h>

unsigned char max = CHAR_MAX + 1;
for (char i = 0; i < max; ++i) {
  printf("i=0x%08x max=0x%08x\n", i, max);
}

Compliant Solution

There are several ways to rectify this example. One way is to treat both chars as unsigned, which prevents wraparound:

#include <limits.h>

unsigned char max = CHAR_MAX + 1;
for (unsigned char i = 0; i < max; ++i) {
  printf("i=0x%08x max=0x%08x\n", i, max);
}

Noncompliant Code Example

This noncompliant code example, adapted from the Cryptography Services blog, demonstrates how signed overflow can occur even when it seems that only unsigned types are in use:

unsigned short x = 45000, y = 50000;
unsigned int z = x * y;

On implementations where short is 16 bits wide and int is 32 bits wide, the program results in undefined behavior due to signed overflow. This is because the unsigned shorts become signed when they are automatically promoted to integer, and their mathematical product (2250000000) is greater than the largest signed 32-bit integer (2³¹ - 1, which is 2147483647).

Compliant Solution

In this compliant solution, by manually casting one of the operands to unsigned int, the multiplication will be unsigned and so will not result in undefined behavior:

unsigned short x = 45000, y = 50000;
unsigned int z = x * (unsigned int)y;

Risk Assessment

Misunderstanding integer conversion rules can lead to errors, which in turn can lead to exploitable vulnerabilities. The major risks occur when narrowing the type (which requires a specific cast or assignment), converting from unsigned to signed, or converting from negative to unsigned.

Automated Detection

Related Vulnerabilities

This vulnerability in Adobe Flash arises because Flash passes a signed integer to calloc(). An attacker has control over this integer and can send negative numbers. Because calloc() takes size_t, which is unsigned, the negative number is converted to a very large number, which is generally too big to allocate, and as a result, calloc() returns NULL, causing the vulnerability to exist.

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

Related Guidelines

Bibliography

...

...

Image Modified Image Modified Image Modified