clone() Method Without super.clone()
Draft Variant
Structure: Simple
Description
The product contains a clone() method that does not call super.clone() to obtain the new object.
All implementations of clone() should obtain the new object by calling super.clone(). If a class does not follow this convention, a subclass's clone() method will return an object of the wrong type.
Common Consequences 1
Scope: IntegrityOther
Impact: Unexpected StateQuality 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 super.clone() within your clone() method, when obtaining a new object.
Phase: Implementation
In some cases, you can eliminate the clone method altogether and use copy constructors.
Demonstrative Examples 1
The following two classes demonstrate a bug introduced by not calling super.clone(). Because of the way Kibitzer implements clone(), FancyKibitzer's clone method will return an object of type Kibitzer instead of FancyKibitzer.
Code Example:
Bad
Java
javaApplicable Platforms
Languages:
Java : Undetermined
Modes of Introduction
Implementation
Related Weaknesses
Taxonomy Mapping
- Software Fault Patterns