CWE-824¶
Access of Uninitialized Pointer. [Pointer-Issues, Improper-Control-Of-A-Resource-Through-Its-Lifetime]
Required inputs: IR
If the pointer contains an uninitialized value, then the value might not point to a valid memory location. This could cause the product to read from or write to unexpected memory locations, leading to a denial of service. If the uninitialized pointer is used as a function call, then arbitrary functions could be invoked. If an attacker can influence the portion of uninitialized memory that is contained in the pointer, this weakness could be leveraged to execute code or perform other attacks.
Depending on memory layout, associated memory management behaviors, and product operation, the attacker might be able to influence the contents of the uninitialized pointer, thus gaining more fine-grained control of the memory location to be accessed.
Excerpts from CWE [https://cwe.mitre.org], Copyright (C) 2006-2026, the MITRE Corporation. See section 9.4. "3rd-Party Licenses" in the documentation for full details.Possible Messages
Key |
Text |
Severity |
Disabled |
|---|---|---|---|
assigned_to_pointer_to_const |
Assigning the address of a partially initialized variable to some pointer-to-const |
None |
False |
pass_as_pointer_to_const_param |
Passing uninitialized variable by pointer as function parameter with pointer-to-const type |
None |
False |
possible_return_value_uninit |
Function return value is potentially not initialized |
None |
False |
possible_uninit |
Use of possibly uninitialized variable |
None |
False |
possibly_initialized |
Use of possibly uninitialized variable (previous call {node0} might have initialized the variable) |
None |
False |
return_value_uninit |
Function return value is not initialized |
None |
False |
uninit |
Use of uninitialized variable |
None |
False |
Options¶
This rule shares the following common options: exclude_in_macros, exclude_messages_in_system_headers, excludes, extend_exclude_to_macro_invocations, includes, justification_checker, languages, post_processing, provider, report_at, severity
The following places define options that affect this rule: Stylechecks, Analysis-GlobalOptions
additional_local_array_check¶
additional_local_array_check : bool = True
int example()
{
int a[10];
int b[20];
int uninit_var;
for (int i = 0; i < 10; ++i)
{
L1: a[i] = uninit_var; // use of uninit_var reported
b[i] = i;
}
int result = a[3]; // not reported, since already reported at L1
result += b[15]; // reported; c[] is not (completely) initialized
return result;
}
assume_globals_are_initialized¶
assume_globals_are_initialized : bool = True
check_array_access_with_unknown_index¶
check_array_access_with_unknown_index : bool = False
a[i] with non-literal index
i should be checked as well.
exclude_from_pointer_to_const_param_check¶
exclude_from_pointer_to_const_param_check : set[bauhaus.analysis.config.QualifiedName] = {'__builtin_object_size'}
track_conditional_initialization¶
track_conditional_initialization : bool = True
use_semantic_analysis¶
use_semantic_analysis : bool = True
writing_into_pointer_to_const¶
writing_into_pointer_to_const
Names of routines (mapping to parameter index, starting at 0) having a parameter declared as pointer-to-const yet they are still writing into the pointee.Type: dict[bauhaus.analysis.config.QualifiedName, int]
Default:
{ 'cudaMemcpyToSymbol': 0 }