Evaluating
...
a pointer—including dereferencing the pointer, using it as an operand of an arithmetic operation, type casting it,
...
and using
...
it as the right-hand side of an
...
assignment—into memory that has been deallocated by a memory management function is undefined behavior. Pointers to memory that
...
has been deallocated are
...
called dangling pointers. Accessing a dangling pointer can result in exploitable vulnerabilities.
According to the C Standard, tusing using the value of a pointer that refers to space deallocated by a call to the free()
or realloc()
function is undefined behavior. (see See undefined behavior 177.).
Reading a pointer to deallocated memory is undefined behavior because the pointer value is indeterminate and might be a trap representation. Fetching a trap representation might perform a hardware trap (but is not required to).
...
In this noncompliant code example, buf
is written to after it has been freed. Write-after-free vulnerabilities can be exploited to run arbitrary code with the permissions of the vulnerable process and are seldom this obvious. Typically, allocations and frees are far removed, making it difficult to recognize and diagnose these problems.
...
Code Block | ||||
---|---|---|---|---|
| ||||
void gdClipSetAdd(gdImagePtr im, gdClipRectanglePtr rect) {
gdClipRectanglePtr more;
if (im->clip == 0) {
/* ... */
}
if (im->clip->count == im->clip->max) {
more = gdRealloc (im->clip->list,(im->clip->max + 8) *
sizeof (gdClipRectangle));
/*
* If the realloc fails, then we have not lost the
* im->clip->list value.
*/
if (more == 0) return;
im->clip->max += 8;
}
im->clip->list[im->clip->count] = *rect;
im->clip->count++;
} |
Compliant Solution
This compliant solution simply reassigns im->clip->list
to the value of more
after the call to realloc()
:
Code Block | ||||
---|---|---|---|---|
| ||||
void gdClipSetAdd(gdImagePtr im, gdClipRectanglePtr rect) { gdClipRectanglePtr more; if (im->clip == 0) { /* ... */ } if (im->clip->count == im->clip->max) { more = gdRealloc (im->clip->list,(im->clip->max + 8) * sizeof (gdClipRectangle)); if (more == 0) return; im->clip->max += 8; im->clip->list = more; } im->clip->list[im->clip->count] = *rect; im->clip->count++; } |
Risk Assessment
Reading memory that has already been freed can lead to abnormal program termination and denial-of-service attacks. Writing memory that has already been freed can additionally lead to the execution of arbitrary code with the permissions of the vulnerable process.
...
Programmers should be wary when freeing memory in a loop or conditional statement; if coded incorrectly, these constructs can lead to double-free vulnerabilities. It is also a common error to misuse the realloc()
function in a manner that results in double-free vulnerabilities. (see See MEM04-C. Beware of zero-length allocations.).
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
MEM30-C | High | Likely | Medium | P18 | L1 |
Automated Detection
Tool | Version | Checker | Description |
---|
Astrée |
|
|
|
ALLOC.UAF
dangling_pointer_use | Supported Astrée reports all accesses to freed allocated memory. | ||||||||
Axivion Bauhaus Suite |
| CertC-MEM30 | Detects memory accesses after its deallocation and double memory deallocations | ||||||
CodeSonar |
| ALLOC.UAF | Use after free | ||||||
Compass/ROSE | |||||||||
|
| USE_AFTER_FREE | Can detect the specific instances where memory is deallocated more than once or read/written to the target of a freed pointer |
5.0
Double Free
UFM.DEREF.MIGHT
UFM.DEREF.MUST
UFM.RETURN.MIGHT
UFM.RETURN.MUST
UFM.USE.MIGHT
UFM.USE.MUST
51 D
Fully implemented
Related Vulnerabilities
VU#623332 describes a double-free vulnerability in the MIT Kerberos 5 function krb5_recvauth().
Search for other vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
...
Accessing freed memory [accfree]
Freeing memory multiple times [dblfree]
...
Cppcheck |
| doubleFree deallocret deallocuse | Partially implemented | ||||||
Cppcheck Premium |
| doubleFree deallocret deallocuse | Partially implemented | ||||||
Helix QAC |
| DF4866, DF4867, DF4868, DF4871, DF4872, DF4873 C++3339, C++4303, C++4304 | |||||||
Klocwork |
| UFM.DEREF.MIGHT UFM.DEREF.MUST UFM.FFM.MIGHT UFM.FFM.MUST UFM.RETURN.MIGHT UFM.RETURN.MUST UFM.USE.MIGHT UFM.USE.MUST | |||||||
LDRA tool suite |
| 51 D, 484 S, 112 D | Partially implemented | ||||||
Parasoft C/C++test |
| CERT_C-MEM30-a | Do not use resources that have been freed | ||||||
Parasoft Insure++ | Runtime analysis | ||||||||
PC-lint Plus |
| 449, 2434 | Fully supported | ||||||
Polyspace Bug Finder |
| Checks for:
Rule partially covered. | |||||||
PVS-Studio |
| V586, V774 | |||||||
Splint |
| ||||||||
TrustInSoft Analyzer |
| dangling_pointer | Exhaustively verified (see one compliant and one non-compliant example). |
Related Vulnerabilities
VU#623332 describes a double-free vulnerability in the MIT Kerberos 5 function krb5_recvauth().
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
Key here (explains table format and definitions)
Taxonomy | Taxonomy item | Relationship |
---|---|---|
CERT C Secure Coding Standard | MEM01-C. Store a new value in pointers immediately after free() | Prior to 2018-01-12: CERT: Unspecified Relationship |
CERT C | MEM50-CPP. Do not access freed memory | Prior to 2018-01-12: CERT: Unspecified Relationship |
ISO/IEC TR 24772:2013 | Dangling References to Stack Frames [DCM] | Prior to 2018-01-12: CERT: Unspecified Relationship |
ISO/IEC TR 24772:2013 | Dangling Reference to Heap [XYK] | Prior to 2018-01-12: CERT: Unspecified Relationship |
ISO/IEC TS 17961 | Accessing freed memory [accfree] | Prior to 2018-01-12: CERT: Unspecified Relationship |
ISO/IEC TS 17961 | Freeing memory multiple times [dblfree] | Prior to 2018-01-12: CERT: Unspecified Relationship |
MISRA C:2012 | Rule 18.6 (required) | Prior to 2018-01-12: CERT: Unspecified Relationship |
CWE 2.11 | CWE-416, Use After Free | 2017-07-07: CERT: Exact |
CWE 2.11 | CWE-672 | 2017-07-07: CERT: Rule subset of CWE |
CERT-CWE Mapping Notes
Key here for mapping notes
CWE-672 and MEM30-C
Intersection( MEM30-C, FIO46-C) = Ø CWE-672 = Union( MEM30-C, list) where list =
- Use of a resource, other than memory after it has been released (eg: reusing a closed file, or expired mutex)
CWE-666 and MEM30-C
Intersection( MEM30-C, FIO46-C) = Ø
CWE-672 = Subset( CWE-666)
CWE-758 and MEM30-C
CWE-758 = Union( MEM30-C, list) where list =
- Undefined behavior that is not covered by use-after-free errors
CWE-415 and MEM30-C
MEM30-C = Union( CWE-456, list) where list =
- Dereference of a pointer after freeing it (besides passing it to free() a second time)
...
Bibliography
[ISO/IEC 9899: |
2024] | 7. |
24.3, "Memory Management Functions" | |
[Kernighan 1988] | Section 7.8.5, "Storage Management" |
[OWASP Freed Memory] |
[MIT 2005] |
[Seacord 2013b] | Chapter 4, "Dynamic Memory Management" |
[Viega 2005] | Section 5.2.19, "Using Freed Memory" |
[VU#623332] |
[xorl 2009] | CVE-2009-1364: LibWMF Pointer Use after free() |
...
...