GHSA-gwq9-9ffj-mvrv: High severity maven/org.xerial.snappy:snappy-java vulnerability
Impact Snappy.uncompressCharArray, uncompressShortArray, uncompressIntArray, uncompressLongArray, uncompressFloatArray and uncompressDoubleArray sized the result array by dividing the declared uncompressed byte length by the element size, but native code wrote the full byte length. If the declared length is not a multiple of the element size, up to 7 bytes are written past the end of the Java array, corrupting the heap.
Patches Fixed in 1.1.10.9 (#739). These methods now reject uncompressed lengths that are not a multiple of the element size with SnappyIOException.
Workarounds Check that Snappy.uncompressedLength(input) is a multiple of the element size before calling these methods.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/org.xerial.snappy:snappy-javato a version that resolves this vulnerability.Fixed in 1.1.10.9 - Upgrade
Upgrade
xerial/snappy-javato a version that resolves this vulnerability.Fixed in 1.1.10.9 - Compensating control
Before calling Snappy.uncompressCharArray, uncompressShortArray, uncompressIntArray, uncompressLongArray, uncompressFloatArray, or uncompressDoubleArray, check that Snappy.uncompressedLength(input) is a multiple of the element size.
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications using org.xerial.snappy:snappy-java and calling one of the affected typed uncompression methods are exposed when they process compressed input whose declared uncompressed length is not divisible by that method's element size. The affected methods are uncompressCharArray, uncompressShortArray, uncompressIntArray, uncompressLongArray, uncompressFloatArray, and uncompressDoubleArray.
What does an attacker need to trigger the heap corruption?
An attacker needs to supply compressed input with a declared uncompressed byte length that is not a multiple of the element size for the typed array method the application calls. No authentication or user interaction is indicated by the supplied vector.
Are applications using the affected methods safe by default?
No. The vulnerable methods allocate the Java result array using a truncated element count, while native code writes the declared byte length; malformed lengths can therefore write up to 7 bytes beyond the array.
What can be done if updating is not immediately possible?
Before calling an affected typed uncompression method, call Snappy.uncompressedLength(input) and verify that the returned value is a multiple of that method's element size. Reject input that fails this check.
Which release contains the fix, and how does it change behavior?
The issue is fixed in version 1.1.10.9. Fixed methods reject declared uncompressed lengths that are not multiples of the element size by throwing SnappyIOException.