org.xerial.snappy:snappy-java: Double release of pooled buffers in SnappyFramedInputStream can share a buffer across streams
What fixes it
- 1.1.10.10org.xerial.snappy:snappy-java, mavenGitHub
<dependency><groupId>org.xerial.snappy</groupId><artifactId>snappy-java</artifactId><version>1.1.10.10</version></dependency>
A fixed version on one release line is not the upgrade target for every line. Check your exact version and any vendor backports.
Description
Impact
When SnappyFramedInputStream needed larger buffers, it returned its current buffers to the buffer pool before allocating replacements. If the allocation failed (for example with OutOfMemoryError caused by a large declared chunk length), the stream still referenced the released buffers, and close() released them to the pool a second time. The default CachingBufferPool does not detect duplicates, so two later SnappyFramedInputStream instances could receive the same backing array, and one stream's decompressed data could be read or overwritten through another.
Patches
Fixed in 1.1.10.10 (#747). Buffer fields are cleared right after release, so a failed allocation can no longer lead to a second release.
Workarounds
Discard the buffer pool after an OutOfMemoryError during decompression, or pass a non-caching BufferPool to SnappyFramedInputStream.
Text from GitHub Advisory Database
Affected versions 1
- org.xerial.snappy:snappy-java, maven<= 1.1.10.9GitHub