> This issue was reported by: Yakov Shafranovich > ([yako...@amazon.com](mailto:yako...@amazon.com)) > > Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a > negative array length in the deserialization stream. Instead it calls > `j.l.r.Array::newInstance(..)` with the negative length which results in a > `NegativeArraySizeException`. NegativeArraySizeException is an unchecked > exception which is neither declared in the signature of > `ObjectInputStream::readObject()` nor mentioned in its API specification. It > is therefore not obvious for users of `ObjectInputStream::readObject()` that > they may have to handle `NegativeArraySizeException`s. It would therefor be > better if a negative array length in the deserialization stream would be > automatically wrapped in an `InvalidClassException` which is a checked > exception (derived from `IOException` via `ObjectStreamException`) and > declared in the signature of `ObjectInputStream::readObject()`. > > If we do the negative array length check in `ObjectInputStream::readObject()` > before filtering, this will then also fix > `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as: > > Returns: > the non-negative number of array elements when deserializing an array of the > class, otherwise -1 > > but currently returns a negative value if the array length is negative.
Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: Fixed comment in 'buildPriorityQueuePayload()' ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13540/files - new: https://git.openjdk.org/jdk/pull/13540/files/4762023a..e351073e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13540&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13540&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13540.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13540/head:pull/13540 PR: https://git.openjdk.org/jdk/pull/13540
