Page History

...

• Use of locks or other synchronization-based mechanisms within a finalizer can cause deadlock or starvation. This possibility arises because both the invocation order and the executing thread or threads for finalizers cannot be guaranteed or controlled.

Noncompliant Code Example

This noncompliant code example uses the System.runFinalizersOnExit() method to simulate a garbage collection run. Note that this method is deprecated because of thread-safety issues; see guideline MET15-J. Do not use deprecated or obsolete methods.

...

Subclass finalize!
Superclass finalize!
This is sub-class! The date object is: null

Compliant Solution

This compliant solution eliminates the call to the overridable doLogic() method from within the finalize() method.

class BaseClass {
  protected void finalize() throws Throwable {
    System.out.println("superclass finalize!");
    // Eliminate the call to the overridden doLogic().
  }
  ...
}

Compliant Solution (Finalization)

Joshua Bloch \[[Bloch 2008|AA. Bibliography#Bloch 08]\] suggests implementing a {{stop()}} method explicitly such that it leaves the class in an unusable state beyond its lifetime. A {{private}} field within the class can signal whether the class is unusable. All the class methods must check this field prior to operating on the class. This is akin to *OBJ04-EX1* discussed in guideline [OBJ04-J. Do not allow access to partially initialized objects]. As always, a good place to call the termination logic is in the {{finally}} block.

Exceptions

OBJ02-EX1: Sometimes it is necessary to use finalizers especially when working with native code. This is because the garbage collector cannot re-claim memory used by code written in another language. Also, the lifetime of the object is often unknown. Again, the native process must not perform any critical jobs that require immediate resource deallocation.

...

The ordering problem can be dangerous when dealing with native code. For example, if object A references object B (either directly or reflectively) and the latter gets finalized first, A's finalizer may end up dereferencing dangling native pointers. To impose an explicit ordering on finalizers, make sure that B is reachable before A's finalizer has concluded. This can be achieved by adding a reference to B in some global state variable and removing it as soon as A's finalizer gets executed. An alternative is to use the java.lang.ref references.

Risk Assessment

Improper use of finalizers can result in resurrection of garbage-collection ready objects and result in denial of service vulnerabilities.

Automated Detection

TODO

Related Vulnerabilities

AXIS2-4163

Bibliography

\[[API 2006|AA. Bibliography#API 06]\] [finalize()|http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#finalize()]
\[[Bloch 2008|AA. Bibliography#Bloch 08]\] Item 7, Avoid finalizers
\[[Boehm 2005|AA. Bibliography#Boehm 05]\] 
\[[Coomes 2007|AA. Bibliography#Coomes 07]\] "Sneaky" Memory Retention
\[[Darwin 2004|AA. Bibliography#Darwin 04]\] Section 9.5, The Finalize Method
\[[Flanagan 2005|AA. Bibliography#Flanagan 05]\] Section 3.3, Destroying and Finalizing Objects
\[[JLS 2005|AA. Bibliography#JLS 05]\] Section 12.6, Finalization of Class Instances
\[[MITRE 2009|AA. Bibliography#MITRE 09]\] [CWE ID 586|http://cwe.mitre.org/data/definitions/586.html] "Explicit Call to Finalize()", [CWE ID 583|http://cwe.mitre.org/data/definitions/583.html] "finalize() Method Declared Public", [CWE ID 568|http://cwe.mitre.org/data/definitions/568.html] "finalize() Method Without super.finalize()"

...