zlib upgrade due?

[Mike Hearn]

For some time now we've been chasing a very rare data corruption bug in
java.util.zip.Inflater that we think must be a bug in the bundled native
zlib. It gets detected by the CRC32 checks and so surfaces as a failure to
inflate. We believe this because:

1. It only seems to happen on ARM Macs (though we haven't tested on ARM
Linux). We have never seen it on Intel.

2. We have seen it with Apache Commons Compress, which has its own gzip
stream code but which still uses the JDK's inflate.

3. It appears to be a thread safety issue, in that to make it show up we
have to inflate data on many threads simultaneously. We reviewed all the
Java code.

4. This year there have been a run of updates to zlib to fix memory safety
errors of various kinds. There was a security fix that showed up in the JDK
very recently (not sure where it came from), but more generally, there was
a new zlib release in March with a bunch of fixes like "Avoid an undefined
behavior of memcpy" and this weekend news broke of several other security
bugs in zlib.

5. NodeJS users have reported a very similar sounding set of bugs again
that seem specific to ARM Mac:
https://stackoverflow.com/questions/69793334/z-data-error-errno-3-zlib-incorrect-data-check-mba-m1

All this points to zlib containing some latent bug that ARM exposes.

We're thinking of building a custom JDK with an upgraded zlib, but it
occurred that this should probably happen upstream anyway for the security
and bugfix issues alone. Is anyone planning to upgrade zlib anytime soon?
I'd rather backport an upstream fix to our local fork of the JDK than do
the upgrade myself.

Alternatively, well, this rash of bugs in relatively old code seems like
the sort of thing Java was intended to fix. Maybe these days with Panama
vectors and Valhalla it'd be possible to make a performance competitive
zlib implementation? I know those features aren't launched yet but maybe
it'd be a good test case for them once merged in.

thanks,
-mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221017/ceae2204/attachment.htm>