Hi Jonas, Thank you for reaching out and providing all this additional information.
Appreciate it and we are taking it into consideration while looking into how to move forward. Best regards, Ekaterina On Wed, 3 Dec 2025 at 6:08, Jonas Konrad <[email protected]> wrote: > Hi everyone, > > I saw CASSANDRA-21052 on your issue tracker and wanted to give my input. > I'm the maintainer of the new fork of lz4-java, and the person that > found the security issue. > > As described in the CVE [1], the official lz4-java project has been > discontinued because the maintainer is not reachable and the rest of the > lz4 team does not want to take over. I made the fork to fix the CVE and > ensure future security issues can be fixed more quickly. > > I understand that a fork requires scrutiny, especially given the XZ > backdoor last year. For that reason, I made the 1.8.1 patch easy to > verify. The jar file is almost identical. The diffoscope output [2] > shows only a few build-related changes along with the patch. You can > upgrade to this version first and delay upgrading to newer versions of > the fork that are harder to verify. > > For the 1.8.1 release, the Sonatype folks also created a relocation pom > [3] with approval of the lz4 project. Depending on > org.lz4:lz4-java:1.8.1 is equivalent to at.yawk.lz4:lz4-java:1.8.1. This > should make the upgrade even easier, though I'm investigating issues > with gradle when the old coordinate is used. > > Regarding impact of the CVE and patch on cassandra, there are multiple > factors to consider. The first is which implementation approach is used: > safe java, sun.misc.Unsafe, or JNI. When using `.fastestInstance`, > normally JNI is used, but it can fall back on the other two options. > > The second factor is which APIs are used on the decompressor. There is a > fastDecompressor and a safeDecompressor. The former is vulnerable for > JNI, while the latter is not. For sun.misc.Unsafe, all decompressors > (and possibly compressors) are vulnerable. > > While researching this CVE, I found that the JNI fastDecompressor > vulnerability had actually been "patched" in CASSANDRA-15560, but this > was never reported upstream. That issue says you moved to the safe > decompressor, which would mitigate much of the CVE. However I can't say > whether *all* uses of fastDecompressor were replaced. Also, on platforms > where the JNI implementation is not used and lz4-java falls back to > sun.misc.Unsafe, even safeDecompressor is vulnerable, so moving at least > to 1.8.1 is still advisable. > > Regarding performance impact of the patch: If you are using vulnerable > implementations (JNI + fastDecompressor, Unsafe), the performance impact > is considerable. If you are using non-vulnerable implementations (JNI + > safeDecompressor), there is no change. So if you moved to > safeDecompressor in CASSANDRA-15560, there should be no performance > problems. > > Let me know if you have any questions. > > - Jonas Konrad > > [1] https://sites.google.com/sonatype.com/vulnerabilities/cve-2025-12183 > [2] https://github.com/yawkat/lz4-java/wiki/1.8.1-diffoscope-output > [3] > https://repo1.maven.org/maven2/org/lz4/lz4-java/1.8.1/lz4-java-1.8.1.pom >
