Integer types in C have two metrics associated with them, a size and a width. The size indicates the number of bytes used by a variable, and can be retrieved for any variable or type using the sizeof
operator, while the width indicates the number of bits that are actually used to encode the integer's value. The C standard permits an integer to contain internal padding bits; these contribute to the integer's size, but not to its width. Consequently, an integer type may have a size that could be used to incorrectly assume its width is larger than it actually is. Do not use the sizeof
operator to compute the width of an integer type.
Noncompliant Code Example
This noncompliant code example illustrates a function that produces 2 raised to the power of the function argument. To prevent undefined behavior, in compliance with INT34-C. Do not shift a negative number of bits or more bits than exist in the operand, the function ensures that the argument is less than the number of bits used to store an unsigned int
.
unsigned int pow2(unsigned int exp) { if (exp > sizeof( unsigned int) * CHAR_BIT) { /* handle error */ } return 1 << exp; }
However, if this code runs on a platform where unsigned int
has one or more padding bits, it can still accept values for exp
that are too large. For instance, a platform that stores unsigned int
in 64 bits, but uses only 48 width bits could perform a left shift on an illegal value of 56.
Compliant Solution
This compliant solution eliminates the possibility of undefined behavior resulting from a left-shift operation on unsigned integers:
unsigned int ui_a; unsigned int ui_b; unsigned int uresult; void func( void ) { /* Initialize ui_a and ui_b */ size_t width = /* width of unsigned int */ if (ui_b >= width) { /* Handle error condition */ } else { uresult = ui_a << ui_b; } /* ... */ } |
Modulo behavior resulting from left-shifting an unsigned integer type is permitted by this standard.
The computation of the correct width of any integer type can be nontrivial. On machines with no padding bits, the width can be computed directly from the integer's size:
size_t width = sizeof (unsigned int ) * CHAR_BIT; |
Some platforms provide a population count operation, which counts the number of bits that are set. This can be used to compute the width:
size_t width = _popcount(UINT_MAX); |
For other platforms, you can implement _popcount
yourself:
unsigned int val = UINT_MAX; size_t width = 0; while (val != 0) { width++; val >>= 1; } |
Noncompliant Code Example (Right Shift)
The result of E1 >> E2
is E1
right-shifted E2
bit positions. If E1
has an unsigned type or if E1
has a signed type and a nonnegative value, the value of the result is the integral part of the quotient of E1
/ 2
E2
. If E1
has a signed type and a negative value, the resulting value isimplementation-defined and can be either an arithmetic (signed) shift:
or a logical (unsigned) shift:
This noncompliant code example fails to test whether the right operand is greater than or equal to the width of the promoted left operand, allowing undefined behavior:
unsigned int ui_a; unsigned int ui_b; unsigned int uresult; void func( void ) { /* Initialize ui_a and ui_b */ uresult = ui_a >> ui_b; /* ... */ } |
Making assumptions about whether a right shift is implemented as an arithmetic (signed) shift or a logical (unsigned) shift can also lead tovulnerabilities. See INT13-C. Use bitwise operators only on unsigned operands.
Compliant Solution (Right Shift)
This compliant solution tests the suspect shift operations to guarantee there is no possibility of undefined behavior:
#include <limits.h> unsigned int ui_a; unsigned int ui_b; unsigned int uresult; void func( void ) { /* Initialize ui_a and ui_b */ size_t width = /* width of unsigned int */ if (ui_b >= width) { /* Handle error condition */ } else { uresult = ui_a >> ui_b; } /* ... */ } |
Implementation Details
GCC has no options to handle shifts by negative amounts or by amounts outside the width of the type predictably or trap on them; they are always treated as undefined. Processors may reduce the shift amount modulo the width of the type. For example, 32-bit shifts are implemented using the following instructions on IA-32:
sa[rl]l %cl, %eax |
The sa[rl]l
instructions take a bit mask of the least significant 5 bits from %cl
to produce a value in the range [0, 31] and then shift %eax
that many bits:
64 bit shifts become sh[rl]dl %eax, %edx sa[rl]l %cl, %eax |
where %eax
stores the least significant bits in the doubleword to be shifted, and %edx
stores the most significant bits.
Risk Assessment
Although shifting a negative number of bits or more bits than exist in the operand is undefined behavior in C, the risk is generally low because processors frequently reduce the shift amount modulo the width of the type.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
INT34-C | low | unlikely | medium | P2 | L3 |
Automated Detection
Tool | Version | Checker | Description |
---|---|---|---|
|
| Can detect violations of this rule. Unsigned operands are detected when checking for INT13-C. Use bitwise operators only on unsigned operands | |
ECLAIR | 1.2 | CC2.INT34 | Partially implemented |
5.0 |
| Can detect violations of this rule with CERT C Rule Pack | |
8.5.4 | 403 S | Partially implemented | |
PRQA QA-C | 8.1 | 0499 | Partially implemented |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
Bibliography
[Dowd 2006] | Chapter 6, "C Language Issues" |
[C99 Rationale 2003] | Subclause 6.5.7, "Bitwise Shift Operators" |
[Seacord 2013] | Chapter 5, "Integer Security" |
[Viega 2005] | Section 5.2.7, "Integer Overflow" |
A test program for this rule is available at www.securecoding.cert.org.