Thanks!

It's interesting that this fails CI so hard, I haven't seen this before. Maybe you can try to re-push this as empty commit, trigger CI, and validate that it is green on main.

I suspect the issue is that 1.3.2 added code (e.g. madler/zlib@5c47755) that checks input pointers for NULL but did not add a #include of a header that defines NULL.

src/zlib/compress.c(31): error C2065: 'NULL': undeclared identifier

On the platforms where the build of compress.c is successful (I tried Linux ppc64le), the #include <stddef.h> in the check to define z_size_t in zconf.h has the side effect of defining NULL. I don't know whether the intention is to now include <stddef.h> or <stdlib.h> all the time or to use Z_NULL from zlib.h. Based on the comment on the Z_NULL definition, I suspect the former since the pointers here are coming from the user and not necessarily from zalloc/zfree.

The strange thing is that the checks log for the 1.3.2 commit shows that the CI passed on some of the platforms that are failing here.

The strange thing is that the checks log for the 1.3.2 commit shows that the CI passed on some of the platforms that are failing here! This might hint at something we can do in the build script maybe.

Some defines have been removed to make this work. And while CI is happy, could this have side-effects?

Also, are there other or more common solutions to do this?

I've opened an issue with the zlib maintainer here madler/zlib#1197

Ideally zlib should be corrected to more consistent behaviour defining NULL across different platforms

The current version of zlib is vulnerable to CVE-2026-22184

FWIW, this did not effect zlib, see madler/zlib#1142 (comment)

Thanks a lot for chiming in @tbeu!

Indeed, I think this PR makes no sense on the grounds of fixing a vulnerability. However, it might have an impact improving Zlib's downstream compatibility, let's see what comes out of it.

If they decline it, I think we need to go forward with this change to support zlib in this and future versions.

Meanwhile, I put it back into draft until it's clear what to do.

The current version of zlib is vulnerable to CVE-2026-22184

FWIW, this did not effect zlib, see madler/zlib#1142 (comment)

Apologies @tbeu. That appears to be the wrong CVE number. CVE-2026-27171 claims to affect zlib 1.3.1 and below. As a result, Mend / Whitesource, is flagging zlib-sys which uses zlib 1.3.1 in our code as vulnerable. The issue is a loop that become an infinite loop for some inputs (madler/zlib#904).

Ok, I had it researched and it seems we should just merge this.

CVE-2026-27171 / GHSA-h858-mf2m-8jf4 says zlib before 1.3.2 can hit unbounded CPU consumption in crc32_combine64 and crc32_combine_gen64 when given a negative length. GitHub marks it low severity and unreviewed, and upstream fixed it in commit ba829a4 with exp
licit negative-length checks. On March 1, 2026, Mark Adler confirmed that commit is the fix for the CVE. Sources: GHSA-h858-mf2m-8jf4, madler/zlib#904 (comment),
madler/zlib@ba829a4

For libz-sys specifically:

• origin/main and release 1.1.24 still point the vendored stock-zlib submodule at 51b7f2a, which is zlib v1.3.1, so the bundled copy is in the affected version range.
• libz-sys exposes crc32_combine:348, and upstream stock zlib implements that via crc32_combine64(... crc32_combine_gen64(len2)), so the exposed API does reach the vulnerable path.
• But libz-sys does not always use the vendored copy. Its build script prefers a system zlib when available, and only builds bundled stock zlib in cases like Windows/MSVC, MinGW, explicit static builds, or fallback when no system zlib is found. See build.rs:16,
  build.rs:34, build.rs:74, and build.rs:83.

So the precise answer is:

• It does apply to libz-sys when libz-sys builds or ships its bundled stock zlib 1.3.1.
• It does not apply when libz-sys links against a system zlib that is already patched to 1.3.2 or distro-backported equivalent.
• It does not apply to zlib-ng mode.

Practical nuance: this is a narrow issue. It requires calling the combine API with an invalid negative length, which upstream originally described as caller misuse, not a normal decompression path. So I would treat it as a real but low-severity issue, not a
panic situation. Still, for the crate release and for scanner noise, updating the bundled zlib to 1.3.2 is the right move.

That leaves my recommendation unchanged: merge PR 259 after correcting the PR description to reference CVE-2026-27171, not the earlier mistaken CVE.

For me to be able to create a new release, I'd need someone who isn't me to bump the crate version in a separate PR.
Thanks