Serialization can extend the lifetime of objects, consequently preventing garbage collection of those objects. The ObjectOutputStream
ensures that each object is written to the stream only once by retaining a reference (or handle) to each object written to the stream. When an previously-written object is subsequently written to the stream again, it is replaced with a reference to the originally-written data in the stream. Note that this substitution takes place without regard to whether the object's contents have changed in the interim. This table of references prevents garbage collection of the previously-written objects because the garbage collector cannot collect live references.
This behavior is both desirable and correct for data that potentially contains arbitrary object graphs, especially when the graphs are fully allocated and constructed prior to serialization. However, it can lead to memory exhaustion when serializing data that both lacks references to other objects being serialized and also can be allocated in part or in full after serialization has begun. One example of such data is serializing a data stream from an external sensor. In such cases, programs must take additional action to avoid memory exhaustion. That is, programs reading in independent serialized data must reset the object cache between reads to prevent memory exhaustion.
This rule is a specific instance of the more general rule MSC07-J. Do not assume infinite heap space.
Noncompliant Code Example
This noncompliant code example reads and serializes data from an external sensor. Each invocation of the readSensorData()
method returns a newly created SensorData
instance, containing a megabyte of data. SensorData
instances contain data and arrays, but lack any references to other SensorData
objects; this is a pure data stream.
The ObjectOutputStream
maintains a cache of previously-written objects, as discussed above; consequently, all SensorData
objects remain alive until the cache itself becomes garbage. This can result in an OutOfMemoryError
, because the stream remains open while new objects are being written to it.
class SensorData implements Serializable { // 1MB of data per instance! ... public static SensorData readSensorData() {...} public static boolean continueReading() {...} } class SerializeSensorData { public static void main(String[] args) throws IOException { ObjectOutputStream out = new ObjectOutputStream( new BufferedOutputStream(new FileOutputStream("ser.dat"))); while (SensorData.continueReading()) { // note that each SensorData object is 1MB in size SensorData sd = SensorData.readSensorData(); out.writeObject(sd); } out.close(); } }
Compliant Solution
This compliant solution takes advantage of the known properties of the sensor data by resetting the output stream after each write. The reset clears the output stream's internal object cache; consequently, the cache no longer maintains references to previously-written SensorData
objects. The garbage collector is able to collect SensorData
instances that are no longer needed.
class SerializeSensorData { public static void main(String[] args) throws IOException { ObjectOutputStream out = new ObjectOutputStream( new BufferedOutputStream(new FileOutputStream("ser.dat"))); while (SensorData.continueReading()) { // note that each SensorData object is 1MB in size SensorData sd = SensorData.readSensorData(); out.writeObject(sd); out.reset(); // reset the stream } out.close(); } }
Risk Assessment
Memory and resource leaks during serialization can consume all available memory or crash the JVM.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
SER10-J |
low |
unlikely |
low |
P3 |
L3 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
CWE-400 "Uncontrolled Resource Consumption (aka 'Resource Exhaustion')" |
|
|
CWE-770 "Allocation of Resources Without Limits or Throttling" |
Bibliography
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="7e9983c1-2a85-45d6-9245-933a846bee8a"><ac:plain-text-body><![CDATA[ |
[[API 2006 |
AA. Bibliography#API 06]] |
|
]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="bff6cd92-7dce-42f6-8101-813d44f175b2"><ac:plain-text-body><![CDATA[ |
[[Harold 2006 |
AA. Bibliography#Harold 06]] |
13.4. Performance |
]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="b520d279-88a3-4af5-878c-e9b07995d223"><ac:plain-text-body><![CDATA[ |
[[Sun 2006 |
AA. Bibliography#Sun 06]] |
"Serialization specification" |
]]></ac:plain-text-body></ac:structured-macro> |
SER09-J. Do not invoke overridable methods from the readObject method 13. Serialization (SER)