<div dir="ltr">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:<br><br>1. It only seems to happen on ARM Macs (though we haven't tested on ARM Linux). We have never seen it on Intel.<br><br>2. We have seen it with Apache Commons Compress, which has its own gzip stream code but which still uses the JDK's inflate. <br><br>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.<br><br>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. <div><br></div><div>5. NodeJS users have reported a very similar sounding set of bugs again that seem specific to ARM Mac: <a href="https://stackoverflow.com/questions/69793334/z-data-error-errno-3-zlib-incorrect-data-check-mba-m1">https://stackoverflow.com/questions/69793334/z-data-error-errno-3-zlib-incorrect-data-check-mba-m1</a></div><div><br></div><div>All this points to zlib containing some latent bug that ARM exposes.<br><div><br></div><div>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.<br></div><div><br></div><div>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.</div></div><div><br></div><div>thanks,</div><div>-mike</div></div>