Page History

...

According to the C Standard, 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).

...

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():

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.).

Automated Detection

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]

...

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)

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

...

...

Image Modified Image Modified Image Modified