CVE-2026-106449: yawkat LZ4 Java: LZ4BlockInputStream with stopOnEmptyBlock=false recurses once per empty block, causing StackOverflowError
Summary
When LZ4BlockInputStream is configured with stopOnEmptyBlock = false (the mode for reading concatenated block streams), it handles each empty block by calling refill() recursively. A long run of empty blocks exhausts the thread stack and throws StackOverflowError out of read() or skip().
Details
In net.jpountz.lz4.LZ4BlockInputStream.refill():
java if (originalLen == 0 && compressedLen == 0) { if (check != 0) { throw new IOException("Stream is corrupted"); } if (!stopOnEmptyBlock) { refill(); } else { finished = true; } return; }
Each well-formed empty block is 21 bytes and adds one stack frame, with no limit on nesting depth. In local testing, around 10,000 to 100,000 consecutive empty blocks (about 210 KB to 2.1 MB, depending on JIT state and thread stack size) threw StackOverflowError. StackOverflowError is an Error, not an IOException, so callers that only handle I/O errors for corrupt input don't catch it.
Impact
Applications that decode attacker-controlled LZ4Block streams with LZ4BlockInputStream.newBuilder().withStopOnEmptyBlock(false) or the deprecated LZ4BlockInputStream(InputStream, boolean) constructor can have the decoding thread fail with StackOverflowError. The default configuration (stopOnEmptyBlock = true) is not affected. There is no memory corruption. Availability impact only.
Patch
Fixed in lz4-java 1.11.4. Empty blocks are now skipped in a loop instead of by recursion, so any number of consecutive empty blocks uses constant stack space.
For older versions, the workaround is to use the default stopOnEmptyBlock = true for untrusted input, or catch StackOverflowError around the read loop.
Other sources
yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.4, net.jpountz.lz4.LZ4BlockInputStream configured with stopOnEmptyBlock set to false handles each well-formed empty LZ4Block by recursively calling refill(), allowing a long sequence of empty blocks in an attacker-controlled compressed stream to exhaust the decoding thread's stack and throw StackOverflowError. The default stopOnEmptyBlock setting is true and is not affected, and the issue does not cause memory corruption. This issue is fixed in version 1.11.4.
— NVD
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/at.yawk.lz4:lz4-javato a version that resolves this vulnerability.Fixed in 1.11.4 - Upgrade
Upgrade
lz4-javato a version that resolves this vulnerability.Fixed in 1.11.4 - Configuration
Use the default stopOnEmptyBlock = true when decoding untrusted input.
net.jpountz.lz4.LZ4BlockInputStream stopOnEmptyBlock = true - Operational
For older versions, catch StackOverflowError around the read loop.
Event History
Frequently Asked Questions
Which deployments are affected?
Only applications that use net.jpountz.lz4.LZ4BlockInputStream with stopOnEmptyBlock set to false are affected. The default setting is true and is not affected.
What does an attacker need to exploit this?
An attacker needs to supply or control a compressed stream containing a long sequence of well-formed empty LZ4 blocks that is decoded by the affected stream configuration. No privileges or user interaction are required, but exploitation has high attack complexity.
What is the impact if exploitation succeeds?
The decoding thread can exhaust its stack and throw StackOverflowError, resulting in an availability impact for that thread. The issue does not cause memory corruption.
What should be done if updating is not immediately possible?
Avoid configuring LZ4BlockInputStream with stopOnEmptyBlock set to false, particularly when decoding attacker-controlled compressed input. Using the default true setting avoids the affected behavior.
What version fixes the issue?
The issue is fixed in yawkat LZ4 Java version 1.11.4. Versions prior to 1.11.4 are affected when the vulnerable configuration is used.