Hi,

The following vulnerabilities were published for zstd-jni-java.

CVE-2026-87795[0]:
| zstd-jni versions before 1.5.7-14 fail to validate offset and length
| parameters in the ZstdDictCompress constructor, allowing out-of-
| bounds memory reads. Attackers can supply untrusted offset or length
| values to read native heap memory into the compression dictionary,
| typically causing JVM crashes.


CVE-2026-87823[1]:
| zstd-jni before 1.5.7-14 performs 32-bit signed bounds checks on
| three direct-ByteBuffer frame-size native methods, allowing out-of-
| bounds memory reads via negative or overflowing offsets. Attackers
| can supply negative offset values near Integer.MIN_VALUE to read
| unmapped memory, causing JVM termination or extracting arbitrary
| frame size data from unintended memory locations.


CVE-2026-87824[2]:
| zstd-jni before 1.5.7-14 fails to validate the samples buffer
| capacity in Zstd.trainFromBufferDirect, allowing attackers to read
| past buffer boundaries by supplying oversized per-sample lengths.
| Attackers can trigger out-of-bounds memory access by providing
| crafted sample length arrays that cause the native implementation to
| walk past the buffer allocation, resulting in JVM termination.


CVE-2026-87825[3]:
| zstd-jni before 1.5.7-14 contains a use-after-free vulnerability
| where streams and contexts hold a dictionary's shared lock only
| during the load call, allowing the dictionary to be closed while
| still referenced. Attackers can close a dictionary after associating
| it with a stream or context, causing subsequent read or write
| operations to access freed native memory, resulting in silent data
| corruption or JVM crashes.


CVE-2026-87877[4]:
| zstd-jni versions before 1.5.7-14 fail to validate closed state in
| setDict, setLongMax, setLevel and setRefMultipleDDicts methods of
| stream classes. Attackers can call these methods on closed streams
| to write through freed native pointers, corrupting unrelated objects
| or crashing the JVM.


CVE-2026-89045[5]:
| zstd-jni versions 1.4.8-4 through 1.5.7-13 fail to validate negative
| length parameters in ZstdInputStreamNoFinalizer.read(), allowing
| attackers to trigger infinite loops. Attackers can pass negative
| length values to cause the read method to spin indefinitely while
| holding the stream monitor, blocking all other threads from
| accessing the stream.


CVE-2026-89046[6]:
| zstd-jni versions 1.5.5-6 through 1.5.7-13 contain an out-of-bounds
| read vulnerability in Zstd.getFrameContentSize that fails to
| validate negative srcPosition arguments. Attackers can supply
| negative offset values that bypass bounds checks and reach the
| native frame-header parser, causing out-of-bounds memory reads that
| lead to information disclosure or JVM crashes.


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2026-87795
https://www.cve.org/CVERecord?id=CVE-2026-87795
[1] https://security-tracker.debian.org/tracker/CVE-2026-87823
https://www.cve.org/CVERecord?id=CVE-2026-87823
[2] https://security-tracker.debian.org/tracker/CVE-2026-87824
https://www.cve.org/CVERecord?id=CVE-2026-87824
[3] https://security-tracker.debian.org/tracker/CVE-2026-87825
https://www.cve.org/CVERecord?id=CVE-2026-87825
[4] https://security-tracker.debian.org/tracker/CVE-2026-87877
https://www.cve.org/CVERecord?id=CVE-2026-87877
[5] https://security-tracker.debian.org/tracker/CVE-2026-89045
https://www.cve.org/CVERecord?id=CVE-2026-89045
[6] https://security-tracker.debian.org/tracker/CVE-2026-89046
https://www.cve.org/CVERecord?id=CVE-2026-89046

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Hi Olek,

What needs to happen with the Bazel Build System [1,2] before we can
upgrade zstd-jni-java to the current upstream version?  Would it help to
upload 1.5.7-17 to experimental?

Thank you,
tony

[1] https://sources.debian.org/src/zstd-jni-java/1.5.2-5%2Bds-8/debian/README.source
[2] https://salsa.debian.org/bazel-team/meta/-/wikis/Bazel-Dependencies

Hey tony,

I'll check on the dependencies of the current (much newer) version that
we have in sid. I'm also copying the Debian Bazel Discussion List in
case anyone on there knows off the top of their head or can find the
info sooner than I can.

Update: just took a quick peek at the relevant parts of the code and it
is not obvious to me whether a newer version would work, 1.5.2-3 is
still what Bazel upstream has pinned [3], Debian uses a SLIGHTLY newer
version without issues.

Paul, do you have any insights on this? We don't have a robust enough
test suite that I'd be comfortable just doing a rebuild and trusting
that it would work.

Oh, tony, to answer your other question, I see no problem with having
the newer version in experimental. It looks like 1.5.7-14 is the version
that fixed these vulnerabilities. Do you know what the code delta is
between -14 and -17??

Best regards,
-Olek

[3]
https://salsa.debian.org/bazel-team/bazel-bootstrap/-/blob/main/MODULE.bazel#L22

Hi Olek and Tony,

I think it is ok to just upgrade zstd-jni-java to the latest version. If
there's anything failed on bazel side, I'll fix it.
Should be not very hard.



Yours,

Paul

Hi Paul,

Thank you for the response, and Olek, please excuse my delay.  I
regularly get overwhelmed by $dayjob.

I will upload zstd-jni-java to experimental, and then we can upload to
unstable once bazel is ready healthy.

Thanks!
tony