finalize() Method Without super.finalize()

Draft Variant
Structure: Simple
Description

This vulnerability occurs when a Java class overrides the finalize() method but fails to call super.finalize() within it.

Extended Description

In Java, the finalize() method is called by the garbage collector before an object is destroyed. If you override this method in a subclass and omit the call to super.finalize(), you break the cleanup chain. This prevents the parent class from performing its own essential cleanup operations, which can lead to resource leaks like unclosed file handles or database connections. To prevent this, always include super.finalize() as the final action in your overridden finalize method. While modern Java development often recommends using cleaner alternatives like try-with-resources or AutoCloseable for resource management, maintaining the super.finalize() call remains a critical defensive practice in legacy code or when overriding finalize is unavoidable.

Common Consequences 1
Scope: Other

Impact: Quality Degradation

Detection Methods 1
Automated Static AnalysisHigh
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Potential Mitigations 2
Phase: Implementation
Call the super.finalize() method.
Phase: Testing
Use static analysis tools to spot such issues in your code.
Demonstrative Examples 1
The following method omits the call to super.finalize().

Code Example:

Bad
Java
java
Applicable Platforms
Languages:
Java : Undetermined
Modes of Introduction
Implementation
Taxonomy Mapping
  • The CERT Oracle Secure Coding Standard for Java (2011)
  • Software Fault Patterns