Test that the JNI safe decompressor never exposes stale destination bytes #123

CVE-2025-66566 was fixed in the Java decompressor: offset-0 matches are zero-filled and matchOff < destOff throws. The JNI safe decompressor passes out + destOff to LZ4_decompress_safe (net_jpountz_lz4_LZ4JNI.c:271), so upstream's lowPrefix is dest + destOff.

My understanding of upstream lz4.c at the pinned submodule commit:

• matches reaching before lowPrefix are rejected;
• offset-0 matches with offsets below 8 zero the output first (LZ4_write32(op, 0));
• the byte-by-byte path that would keep stale bytes only runs in partial decoding, which we don't use.

So this is most likely fine, but it isn't verified. Add a canary test run against LZ4Factory.nativeInstance().safeDecompressor():

byte[] off0 = {0x1E, 'A', 0, 0, 0x50, 'B','B','B','B','B'};   // literal 'A', match offset 0 len 18, 5 last literals
for (int destOff : new int[]{0, 8}) for (int extra : new int[]{0, 64}) {
  byte[] dest = new byte[destOff + 24 + extra];
  Arrays.fill(dest, (byte) 0x5A);
  try {
    int n = d.decompress(off0, 0, off0.length, dest, destOff, 24 + extra);
    for (int i = destOff; i < destOff + n; i++) assertNotEquals((byte) 0x5A, dest[i]);
  } catch (LZ4Exception expected) {}
}
byte[] back = {0x10, 'A', 2, 0, 0x50, 'B','B','B','B','B'};    // offset reaches before destOff
assertThrows(LZ4Exception.class, () -> d.decompress(back, 0, back.length, new byte[64], 8, 56));

Repeat with direct and heap ByteBuffers, since those take separate JNI branches, and with offsets 1-7 and long offset-0 matches. Also compare the output with safeInstance().safeDecompressor().