Local, automatic variables can assume unexpected values if they are used before they are initialized. The C standard specifies, "If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate" [ISO/IEC 9899:2011]. (See also undefined behavior 11 of Annex J.)
In the common case, on implementations that make use of a program stack, this value defaults to whichever values are currently stored in stack memory. While uninitialized memory often contains zeros, this is not guaranteed. Uninitialized memory has indeterminate value, which for objects of some types can be a trap representation. Reading uninitialized memory is undefined behavior (See undefined behavior 10 of Annex J.) , it can cause a program to behave in an unexpected manner, and provide an avenue for attack.
...
In most cases, compilers warn about uninitialized variables, discussed in MSC00-C. Compile cleanly at high warning levels. In other cases, compilers will completely optimize out the uninitialized variables.
...
This defect results from a failure to consider all possible data states. (See MSC01-C. Strive for logical completeness.) Once the problem is identified, it can be trivially repaired by accounting for the possibility that number can be equal to 0.
...
In this noncompliant code example, the programmer mistakenly fails to set the local variable error_log to the msg argument in the report_error() function [Mercy 2006]. Because error_log has not been initialized, on architectures making use of a program stack, it assumes the value already on the stack at this location, which is a pointer to the stack memory allocated to the password array. The sprintf() call copies data in password until a null byte is reached. If the length of the string stored in the password array is greater than the size of the buffer array, a buffer overflow occurs.
...
This solution is still problematic because a buffer overflow will occur if the null-terminated byte string referenced by msg is greater than 17 bytes, including the NULL terminator. The solution also makes use of a "magic number," which should be avoided. (See DCL06-C. Use meaningful symbolic constants to represent literal values.)
Compliant Solution
In this compliant solution, the magic number is abstracted, and the buffer overflow is eliminated.
...
In this noncompliant code example, the function mbrlen() is passed the address of an automatic mbstate_t object that has not been properly initialized, leading to undefined behavior. See undefined behavior 200 in Annex J of C11 [ISO/IEC 9899:2011].
...
| Tool | Version | Checker | Description | ||||||
|---|---|---|---|---|---|---|---|---|---|
| 57 D | Fully implemented. | |||||||
| Fortify SCA | Can detect violations of this rule, but will return false positives if the initialization was done in another function. | ||||||||
| Splint | V. 3.1.1 | ||||||||
| GCC | V 4.3.5 | Can detect some violations of this rule when the -Wuninitialized flag is used. | |||||||
| Compass/ROSE | Automatically detects simple violations of this rule, although it may return some false positives. It may not catch more complex violations, such as initialization within functions taking uninitialized variables as arguments. It does catch the second noncompliant code example, and can be extended to catch the first as well. | ||||||||
| V. 5.0 | NO_EFFECT | Can find cases of an uninitialized variable being used before it is initialized, although it cannot detect cases of uninitialized members of a struct. Because Coverity Prevent cannot discover all violations of this rule, further verification is necessary. | |||||||
| V. 9.1 | UNINIT.HEAP.MIGHT | ||||||||
| PRQA QA·CQA-C |
| Fully implemented |
...
ISO/IEC TR 17961 (Draft) Referencing uninitialized memory [uninitref]
ISO/IEC TR 24772 "LAV Initialization of variables"
Bibliography
[Flake 2006]
[Mercy 2006]
[Wang 2012] "More Randomness or Less"
[xorl 2009] "CVE-2009-1888: SAMBA ACLs Uninitialized Memory Read"
...