Wild Pointer Article Index for
Wild
Website Links For
Pointer
 

Information About

Wild Pointer





CAUSE OF DANGLING POINTERS


In many languages (particularly the C Programming Language , which assumes the programmer will take care of all design issues, and hence do not include many of the checks that are present in higher-level languages), deleting an object from memory does not alter any associated pointers. The pointer still points to the location in memory where the object or data was, even though the object or data has since been deleted and the memory may now be used for other purposes, creating a dangling pointer.

Other ways of creating dangling pointers are as follows:

  • Use of uninitialized pointers.

  • Pointers to Stack Frame s which have been popped off the runtime stack, i.e. are no longer valid.

  • As a result of inappropriate pointer casts (which may cause the pointer type to not match the type of the object, in typed languages) or inappropriate Pointer Arithmetic .

  • Multiple deletion of an object from the heap (usually called a Double Free bug).


A straightforward example is shown below:

{
  • cp = NULL;

  • ... ---/

  • {

char c;
cp = &c;
  • The memory location, which c was occupying, is released here ---/

  • cp here is now a dangling pointer ---/

  • }


In the above, a better solution to avoid the dangling pointer is to make cp a null pointer after the inner block is exited.

A common programming misstep to create a dangling pointer is returning the address of a local variable. Since local variables are dellocated when the function returns, any pointers that point to local variables will become dangling pointers once the stack frame is deallocated.

  • func ( void )

  • {

char ca {Link without Title} = "Pointers and Arrays - II";
  • ... ---/

  • return ca;

}

If it is required to return the address of ca, declare it with the static storage specifier.

A frequent source of creating dangling pointers is a jumbled combination of malloc() and free() library calls. A pointer becomes dangling, when the block of memory pointed it is freed.

#include
{
  • cp = malloc ( A_CONST );

  • ... ---/

  • cp now becomes a dangling pointer ---/

  • cp is no longer dangling ---/

  • ... ---/

  • }


This is another example of a dangling pointer:

  • i = 0;

  • for (; i < 0xFFFFFFFC; i = i + 4)

{
  • i = 0;

  • }



SECURITY HOLES INVOLVING DANGLING POINTERS


Like Buffer Overflow bugs, dangling pointer bugs are frequently security holes. For example, if the pointer is used to make a Virtual Function call, a different address (possibly pointing at exploit code) may be called due to the Vtable being overwritten. Alternatively, if the pointer is used for writing to memory, some other data structure may be corrupted. Even if the memory is only read once the pointer becomes dangling, it can lead to information leaks (if interesting data is put in the next structure allocated there) or privilege escalation (if the now-invalid memory is used in security checks).


DANGLING POINTER PREVENTION


To avoid bugs of this kind, one common programming technique is to set pointers to the Null Pointer once the storage they point to has been released. When the null pointer is dereferenced (in most languages) the program will immediately terminate — there is no potential for data corruption or unpredictable behavior. This makes the underlying programming mistake easier to find and resolve. This technique does not help when there are multiple copies of the pointer.

Another technique is the use of Smart Pointers . For example, a smart pointer that provides Reference Counting is valid as long as at least one such pointer exists. A smart pointer that provides safe weak references acts like a pointer to NULL once the object has been deleted.

Some other techniques include the Tombstone s method and the Locks-and-keys method.

A code analysis tool, like Lint , can help in finding potential programming mistakes, though it is up to the programmer to ensure a well-behaved program.

Some programming languages, such as Java , have semantics which prevent dangling pointers ("references" in Java parlance) from occurring. In particular, Java has:

  • Mandatory Garbage Collection which prevents memory deallocation errors

  • Guaranteed initialization of all references (unless explicity initialized to something else, references in Java are set to null).

  • The only permitted casts are those which are either guaranteed to be typesafe, or which incur a runtime check to ensure validity.

  • Pointer arithmetic is disallowed.

  • Objects may not be allocated on the stack.


Several other programming languages take similar approaches to prevent dangling pointers from occurring.


DANGLING POINTER DETECTION


Some debuggers will automatically overwrite and destroy data that has been freed, usually with a specific pattern (Microsoft's Visual C/C++ debugger, for example, uses 0xCC, 0xCD or 0xDD depending on what has been freed). This usually prevents the data from being reused by making it useless and also very prominent (the pattern serves to show the programmer that the memory has already been freed).

Tools such as Dhurjati, D. and Adve, V. Efficiently Detecting All Dangling Pointer Uses in Production Servers can also be used to detect uses of dangling pointers.


EXTERNAL LINK



REFERENCES