Do not build zlib with the hand-optimized assembly code.
The ASM code is a contribution and does not receive any support by the library authors. There are bugs in there and it will read/write out of bounds given just the right data - we've been bit by it. Note also [0].
The default Makefile gets this right - it stays far away from any hand-rolled assembly (or contributions in general). But the contributed Visual Studio solutions default to building with the ASM: [1] [2]. Make sure to choose ReleaseWithoutAsm, or set up your own configuration!
You can check any zlib build for whether it was built with ASM via (zlibCompileFlags() & (1 << 9)): [3]
Needless to say, an OOB in a library as fundamental (and as user-data-facing) as zlib is a serious vulnerability. I didn't find any distribution or major software that uses a vulnerable zlib build in a day of investigation (well, I think Telegram Desktop in a debug build might be vulnerable [4]), but if you are on Windows you might accidentally make one. Beware!
I'll also point interested readers towards zlib-ng [5] (without any endorsement or affiliation).
[0]: https://github.com/madler/zlib/blob/master/inffast.c#L12
[1]: https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da...
[2]: https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da...
[3]: https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da...
[4]: https://github.com/telegramdesktop/tdesktop/blob/6a3ad52aef0...