Fix buffer overflows and unbounded allocations from untrusted input (CVE-2026-90559 and others)

[xerial]

Summary

The JNI layer (SnappyNative.cpp) writes through raw pointers with no bounds checks. This PR adds validation in the Java API before every native call, so bad sizes now raise a Java exception instead of crashing the JVM or corrupting memory. The native libraries don't need to be rebuilt.

Issue	Problem	Fix
#728 (CVE-2026-90559)	uncompress(ByteBuffer, ByteBuffer) writes past an undersized destination	Require uncompressed.remaining() >= uncompressedLength(compressed)
#732	compress(ByteBuffer, ByteBuffer) writes past an undersized destination	Require compressed.remaining() >= maxCompressedLength(len)
#717	rawCompress / rawUncompress / uncompress(byte[]…) accept out-of-range offsets and lengths and undersized outputs	Check input ranges against the array's byte size; check output space for compress and uncompress
#729	uncompress{Char,Short,Int,Long,Float,Double}Array under-allocate when the length isn't a multiple of the element size	Reject such lengths with SnappyIOException
#625	uncompress(byte[]) with a 5-byte input leads to an OOM or NegativeArraySizeException	uncompressedLength() rejects negative lengths and lengths above 64/3 × the compressed size
#730	SnappyFramedInputStream allocates from the declared length before the CRC check	Same uncompressedLength() bound: allocation is now proportional to the bytes actually read
#731	Runs of 4-byte skippable chunks cause a StackOverflowError through recursion	Skip chunks in a loop

Why a ratio bound instead of a fixed cap

The densest Snappy element is a 3-byte copy that expands to 64 bytes, so a valid stream can never declare more than 64/3 times its compressed size. The bound rejects only data that would fail to decompress anyway, and it can't break legitimate data. It lives in uncompressedLength(), so it also covers third-party code that does new byte[Snappy.uncompressedLength(x)].

For the framed stream, I left out a hard 64 KiB per-chunk cap (the framing spec limit). The existing testLargerFrames_* tests show the reader accepts larger frames on purpose for compatibility.

Behavior change

Passing an output buffer smaller than maxCompressedLength(n) to compress now throws IllegalArgumentException. The native RawCompress already required that size, and an undersized buffer was undefined behavior before.

Related community PRs

#733, #734, #735, #736 and #737 each fix one of these issues. This PR covers all of them in one consistent change, and thanks to their authors for the reports and proposed fixes.

Test plan

• New SnappyBoundsCheckTest (20 tests) covering each issue's PoC plus valid edge cases: max-ratio data, offset output, empty input
• ./sbt test: 124 passed, 0 failed

🤖 Generated with Claude Code