Local, automatic variables assume unexpected values if they are read before they are initialized. The C++ Standard, [dcl.init], paragraph 12 [ISO/IEC 14882-2014], states the following:
If no initializer is specified for an object, the object is default-initialized. When storage for an object with automatic or dynamic storage duration is obtained, the object has an indeterminate value, and if no initialization is performed for the object, that object retains an indeterminate value until that value is replaced. If an indeterminate value is produced by an evaluation, the behavior is undefined except in the following cases:
— If an indeterminate value of unsigned narrow character type is produced by the evaluation of:
— the second or third operand of a conditional expression,
— the right operand of a comma expression,
— the operand of a cast or conversion to an unsigned narrow character type, or
— a discarded-value expression,
then the result of the operation is an indeterminate value.
— If an indeterminate value of unsigned narrow character type is produced by the evaluation of the right operand of a simple assignment operator whose first operand is an lvalue of unsigned narrow character type, an indeterminate value replaces the value of the object referred to by the left operand.
— If an indeterminate value of unsigned narrow character type is produced by the evaluation of the initialization expression when initializing an object of unsigned narrow character type, that object is initialized to an indeterminate value.
The default initialization of an object is described by paragraph 7 of the same subclause:
To default-initialize an object of type
T
means:
— ifT
is a (possibly cv-qualified) class type, the default constructor forT
is called (and the initialization is ill-formed ifT
has no default constructor or overload resolution results in an ambiguity or in a function that is deleted or inaccessible from the context of the initialization);
— ifT
is an array type, each element is default-initialized;
— otherwise, no initialization is performed.
If a program calls for the default initialization of an object of a const-qualified typeT
,T
shall be a class type with a user-provided default constructor.
As a result, objects of type T
with automatic or dynamic storage duration must be explicitly initialized before having their value read as part of an expression unless T
is a class type or an array thereof or is an unsigned narrow character type. If T
is an unsigned narrow character type, it may be used to initialize an object of unsigned narrow character type, which results in both objects having an indeterminate value. This technique can be used to implement copy operations such as std::memcpy()
without triggering undefined behavior.
Additionally, memory dynamically allocated with a new
expression is default-initialized when the new-initialized is omitted. Memory allocated by the standard library function std::calloc()
is zero-initialized. Memory allocated by the standard library function std::realloc()
assumes the values of the original pointer but may not initialize the full range of memory. Memory allocated by any other means ( std::malloc()
, allocator objects, operator new()
, and so on) is assumed to be default-initialized.
Objects of static or thread storage duration are zero-initialized before any other initialization takes place [ISO/IEC 14882-2014] and need not be explicitly initialized before having their value read.
Reading uninitialized variables for creating entropy is problematic because these memory accesses can be removed by compiler optimization. VU925211 is an example of a vulnerability caused by this coding error [VU#925211].
Noncompliant Code Example
In this noncompliant code example, an uninitialized local variable is evaluated as part of an expression to print its value, resulting in undefined behavior.
#include <iostream> void f() { int i; std::cout << i; }
Compliant Solution
In this compliant solution, the object is initialized prior to printing its value.
#include <iostream> void f() { int i = 0; std::cout << i; }
Noncompliant Code Example
In this noncompliant code example, an int *
object is allocated by a new-expression, but the memory it points to is not initialized. The object's pointer value and the value it points to are printed to the standard output stream. Printing the pointer value is well-defined, but attempting to print the value pointed to yields an indeterminate value, resulting in undefined behavior.
#include <iostream> void f() { int *i = new int; std::cout << i << ", " << *i; }
Compliant Solution
In this compliant solution, the memory is direct-initialized to the value 12
prior to printing its value.
#include <iostream> void f() { int *i = new int(12); std::cout << i << ", " << *i; }
Initialization of an object produced by a new-expression is performed by placing (possibly empty) parenthesis or curly braces after the type being allocated. This causes direct initialization of the pointed-to object to occur, which will zero-initialize the object if the initialization omits a value, as illustrated by the following code.
int *i = new int(); // zero-initializes *i int *j = new int{}; // zero-initializes *j int *k = new int(12); // initializes *k to 12 int *l = new int{12}; // initializes *l to 12
Noncompliant Code Example
In this noncompliant code example, the class member variable c
is not explicitly initialized by a ctor-initializer in the default constructor. Despite the local variable s
being default-initialized, the use of c
within the call to S::f()
results in the evaluation of an object with indeterminate value, resulting in undefined behavior.
class S { int c; public: int f(int i) const { return i + c; } }; void f() { S s; int i = s.f(10); }
Compliant Solution
In this compliant solution, S
is given a default constructor that initializes the class member variable c.
class S { int c; public: S() : c(0) {} int f(int i) const { return i + c; } }; void f() { S s; int i = s.f(10); }
Risk Assessment
Reading uninitialized variables is undefined behavior and can result in unexpected program behavior. In some cases, these security flaws may allow the execution of arbitrary code.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
EXP53-CPP | High | Probable | Medium | P12 | L1 |
Automated Detection
Tool | Version | Checker | Description |
---|---|---|---|
Astrée | 22.10 | uninitialized-read | Partially checked |
Clang | 3.9 | -Wuninitialized clang-analyzer-core.UndefinedBinaryOperatorResult | Does not catch all instances of this rule, such as uninitialized values read from heap-allocated memory. |
CodeSonar | 8.1p0 | LANG.STRUCT.RPL | Return pointer to local Uninitialized variable |
Helix QAC | 2024.3 | DF726, DF2727, DF2728, DF2961, DF2962, DF2963, DF2966, DF2967, DF2968, DF2971, DF2972, DF2973, DF2976, DF2977, DF978 | |
Klocwork | 2024.3 | UNINIT.CTOR.MIGHT UNINIT.CTOR.MUST UNINIT.HEAP.MIGHT UNINIT.HEAP.MUST UNINIT.STACK.ARRAY.MIGHT UNINIT.STACK.ARRAY.MUST UNINIT.STACK.ARRAY.PARTIAL.MUST UNINIT.STACK.MIGHT UNINIT.STACK.MUST | |
LDRA tool suite | 9.7.1
| 53 D, 69 D, 631 S, 652 S | Partially implemented |
Parasoft C/C++test | 2023.1 | CERT_CPP-EXP53-a | Avoid use before initialization |
Parasoft Insure++ | Runtime detection | ||
Polyspace Bug Finder | R2024a | CERT C++: EXP53-CPP | Checks for:
Rule partially covered. |
PVS-Studio | 7.33 | V546, V573, V614, V670, V679, V730, V788, V1007, V1050 | |
RuleChecker | 22.10 | uninitialized-read | Partially checked |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
Bibliography
[ISO/IEC 14882-2014] | Clause 5, "Expressions" Subclause 5.3.4, "New" Subclause 8.5, "Initializers" Subclause 12.6.2, "Initializing Bases and Members" |
[Lockheed Martin 2005] | Rule 142, All variables shall be initialized before use |
4 Comments
Gerhard Muenz
Can you explain why member variable C is not default-initialized in class S? I think it is default initialized with zero according to the rules of C++.
Aaron Ballman
You are correct that
C
is default-initialized and I've corrected the wording to be more clear on this point and what it means. Thank you for pointing this out! However, default-initialization is not zero-initialization, which is why the NCCE is not compliant. Here's the full breakdown of the process:The declaration of
o
inf()
does not specify an initializer. [class.init]p1 specifies that when no initializer is specified for an object of class type, it is initialized as specified in [dcl.init].[dcl.init]p12 specifies that if no initializer is specified for an object, the object is default-initialized. It then goes on to state that the storage for the object has an indeterminate value until initialization is performed on that object.
The behavior of default initialization is specified in [dcl.init]p7 and specifies that for a class type, the default constructor is called. The default constructor is specified in [class.ctor]p4 as being one that is defaulted (since it is not user-provided) but not deleted. p5 goes on to state that such a constructor performs the set of initializations that would be performed by a user-written default constructor for the class with no ctor-initializer and an empty compound statement.
[class.base.init] covers what happens when there's no ctor-initializer in p8. Since
C
has no brace-or-equal-initializer, andC
is not a union or a variant member of the class, we fall into the final bullet that saysC
is default-initialized.That brings us back to [dcl.init]p7, but for the class member
C
. SinceC
is not a class type, or an array type, no initialization is performed onC
. BecauseC
was not initialized, and the storage foro
(which containsC
) has an indeterminate value, accessingC
would evaluate an object with indeterminate value which is undefined behavior per [dcl.init]p12.Gerhard Muenz
Thank you for guiding my through this circular chain of references in the C++11 standard. I've tried it on my own but gave up when I reached §8.5 again, thinking that something must be wrong. Your last paragraph explains why we take a different exit in §8.5.
Actually, I was aware of the problem regarding objects of POD types. This has been discussed in several places, e.g. see:
http://www.fnal.gov/docs/working-groups/fpcltf/Pkg/ISOcxx/doc/POD.html
http://stackoverflow.com/questions/2204176/how-to-initialise-memory-with-new-operator-in-c
Somehow, I did not realize that POD member variables of a non-POD classes are not initialized, either.
As I see, the distinction of POD types and non-POD types was removed in C++11, together with a new definition of "default-initialize" in §8.5 and a different behavior the defaulted default constructor in §12.6.2 .
Am I right that, despite theses changes between C++03 and C++11, the actual behavior regarding initialization is the same in C++03 and C++11? We just now call it default-initialized even if no initialization is performed in C++11?
This is also compliant, isn't it?
class
S {
int
C;
public
:
int
f(
int
I)
const
{
return
I + C; }
};
void
f() {
S o{};
int
i = o.f(10);
}
If yes, we could add this to the example.
We could also extend the example explaining the "new" case with a compliant version using the new-initializer:
void
f() {
int
*i =
new
int
();
std::cout << i <<
", "
<< *i;
}
We could clarify this in the next edition of "Secure Coding in C and C++" (chapter 4.3) as well as in the OLI module.
Aaron Ballman
My pleasure!
The concept of POD remains in a restricted form (only when discussing aggregate types like classes and unions), see [class]p10, but you are correct that initialization has not changed in this regard between C++03 and C++11. The term "default-initialized" sounds like it implies some sort of initialization, but it can also mean "the default is to not initialize."
You are correct about your first code snippet being compliant as that uses direct initialization, which ultimately winds up performing a zero initialization. However, it does not strike me as a safe solution to demonstrate compliance as there is no way to ensure that the programmer uses direct initialization to initialize the object. By making the initialization part of the default constructor, it becomes unavoidable. This has pros and cons (obviously), but I think the pros outweigh the cons in terms of enforcing code correctness.
Good point about the second code snippet being compliant as well (thanks to the presence of () implying direct initialization instead of default initialization). I have updated the code example.