Hi,

The following vulnerability was published for zlib.

CVE-2026-85091[0]:
| zlib versions 1.3.1.2 through 1.3.2 contain a heap buffer overflow
| vulnerability in the gz_vacate() function when processing non-
| blocking gzwrite() operations with stale external buffer pointers.
| Attackers can trigger the overflow by calling gzprintf() or
| gzvprintf() after a write stall, causing an unchecked memmove() to
| write beyond the internal input buffer boundary.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2026-85091
https://www.cve.org/CVERecord?id=CVE-2026-85091
[1] https://gist.github.com/thesmartshadow/e0b9481792afb7c31e86fee1ff084490
[2] https://github.com/madler/zlib/commit/e3dc0a85b7032e98380dec011bc8f2c2ee0d8fca

Regards,
Salvatore

Hi,

FWIW, [2] might not be correct, can you check with upstream?

Regards,
Salvatore

(Sorry Claude wrote this, but if true thought it be helpful for ya'll,
thanks. CVEs this year have been insane!)

Hi,

CVE-2026-85091 is the heap overflow in gz_vacate() (gzwrite.c), reached
through gzprintf()/gzvprintf() after a non-blocking write stall. The
advisory (GHSA-g5fp-32jq-cfw2) gives the affected range as 1.3.1.2
through 1.3.2, and the upstream history agrees:

- gz_vacate() and the non-blocking handling in the gz* routines were
  introduced in upstream commit 81cc0bebedd935daeb81b0b6e475d8786b51af3d
  ("Support non-blocking devices in the gz* routines.", 2025-05-25),
  after the v1.3.1 tag. v1.3.1.2 is the first tag that contains it and
  v1.3.2 (2026-02-17) the first release.
- gzwrite.c at v1.3.1 defines only gz_init, gz_comp, gz_zero and
  gz_write. There is no gz_vacate() and no stall handling: a short or
  failed write() is treated as a fatal Z_ERRNO.

The tracker currently lists trixie (1:1.3.dfsg+really1.3.1-1) and
bookworm (1:1.2.13.dfsg-1) as vulnerable. Both predate the vulnerable
code, so I believe they should be marked <not-affected> (vulnerable code
introduced in 1.3.2), leaving only 1:1.3.dfsg+really1.3.2-* in
forky/sid affected.

Hi Mark,

Attached is a proposed update for zlib in unstable with one related
patch cherry-picked and the upstream commited change for
CVE-2026-85091.

I tested the update as well against the published reporducers, and the
update would be tested as well on
https://debusine.debian.net/debian/developers/work-request/1293184/

Regards,
Salvatore

Hi,

And now attached for real :-(

Regards,
Salvatore

The CVE text limits the affected range to 1.3.1.2 through 1.3.2. That
range is too narrow. The overflow predates non-blocking write support:
I reproduced it under ASan on upstream 1.2.11 and 1.2.13 in both
gz_write() and gzvprintf(). The direct-path code involved dates from
1.2.3.5.

No write stall is needed to reach it. Any gz_comp() failure on the
direct path leaves the same state, so a descriptor opened read-only
reproduces it without sockets or timing.

Method and per-patch results are in my comment on the upstream issue:

https://github.com/madler/zlib/issues/1292#issuecomment-5562455575

Upstream fix, already noted in the tracker:


https://github.com/madler/zlib/commit/df84af25dc1942490e1d1c899a07619152a46148

The commit applies to the bookworm and trixie sources as well as sid,
so a backport of that single hunk covers all three.

Steve Antonakakis

Hello,

The tracker currently lists zlib as vulnerable to CVE-2026-85091 in
bookworm and trixie. As far as I can tell, neither release contains the
vulnerable code.

   - The CVE covers zlib 1.3.1.2 through 1.3.2. The vulnerable function
   gz_vacate() and the non-blocking write code came in with upstream commit
   81cc0be ("Support non-blocking devices in the gz* routines", 25 May 2025).
   That commit is in v1.3.1.2 but not in v1.3.1.
   - trixie (1:1.3.dfsg+really1.3.1-1) ships upstream 1.3.1 with no Debian
   patches. Its gzwrite.c has no gz_vacate().
https://sources.debian.org/src/zlib/1:1.3.dfsg+really1.3.1-1/gzwrite.c/
   - bookworm (1:1.2.13.dfsg-1) predates the commit as well.
   - forky/sid (1:1.3.dfsg+really1.3.2-3) does contain the code (gz_vacate()
   at line 382), so it remains affected:
https://sources.debian.org/src/zlib/1:1.3.dfsg+really1.3.2-3/gzwrite.c/

Upstream discussion: https://github.com/madler/zlib/issues/1310

If the analysis above is correct, could you please mark bookworm and trixie
as not-affected?
Thank you,
Dimitris

Hi,

No, we won't mark it yet as such. The reasons are explained in
https://github.com/madler/zlib/issues/1310#issuecomment-5979623265 ,
https://github.com/madler/zlib/issues/1292#issuecomment-5562455575 and
https://bugs.debian.org/1146895#36 .

So it will depends if upstream will consider this a separate issue or
in scope of the assignment.

Regards,
Salvatore

Hi,

I agree with Salvatore.

Additionally I was able to create an poc [1] that crashes even when not
using the non-blocking API.
The mechanics for the crash are the same as for the non-blocking poc,
namely a crash due the invalid state.

The crash goes away with the upstream fix for CVE-2026-85091 [2],

[1] https://github.com/madler/zlib/issues/1292#issuecomment-597805192
[2]
https://github.com/madler/zlib/commit/df84af25dc1942490e1d1c899a07619152a46148


Whether this will have a dedicated CVE will depend on upstream view on
this issue.

Cheers,
tobi

Hi Mark,

Are you okay with if I upload this NMU to proceed with the fix in
usntable, and we (me for trixie, and Tobias is doing bookworm and
older), to address the issue?

Regards,
Salvatore

Please don't upload anything to unstable, there's a bunch of churn for
cross build and possibly some other stuff I ought to upload anyway.
Whatever you want to do for the releases is OK for me.

We believe that the bug you reported is fixed in the latest version of
zlib, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1146895@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Mark Brown <broonie@debian.org> (supplier of updated zlib package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sun, 25 Oct 2026 22:40:02 +0000
Source: zlib
Architecture: source
Version: 1:1.3.dfsg+really1.3.2-4
Distribution: unstable
Urgency: low
Maintainer: Mark Brown <broonie@debian.org>
Changed-By: Mark Brown <broonie@debian.org>
Closes: 1141300 1146895
Changes:
 zlib (1:1.3.dfsg+really1.3.2-4) unstable; urgency=low
 .
   * Pull in upstream patch to fix void undefined behavior in gzwrite.c.
   * Pull in upstream patch to fix buffer overflow bug in non-blocking
     gzwrite (CVE-2026-85091) (Closes: #1146895).
   * Apply patch from Helmut Grohne <helmut@subdivi.de> making the
     multilib dependencies massively more verbose to avoid cross build
     issues due to incomplete gcc-multilib not being available on some
     architectures (closes: #1141300).
Checksums-Sha1:
 fe42bb63d416e3716a4fd57454f6117297a74a7e 3931 zlib_1.3.dfsg+really1.3.2-4.dsc
 00655a512f6bee30dc3a8ede9a827f693c5cb33c 18988 zlib_1.3.dfsg+really1.3.2-4.debian.tar.xz
Checksums-Sha256:
 5735985df9244ebceb03e606342d3d0bf2fd76284f3ccc939a266b43b559a8e1 3931 zlib_1.3.dfsg+really1.3.2-4.dsc
 ee9db06d87b2d810b9edd8485b8b39433b18eb30d93f9e1d40fe8dbd40eda7a1 18988 zlib_1.3.dfsg+really1.3.2-4.debian.tar.xz
Files:
 bdd9ce491c9505232be99c1d40fb3f2c 3931 libs optional zlib_1.3.dfsg+really1.3.2-4.dsc
 d59fcdbd3ab0221d457793f5e67dfd63 18988 libs optional zlib_1.3.dfsg+really1.3.2-4.debian.tar.xz
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmrejvYACgkQJNaLcl1U
h9CliQf7BTF845QsbzBKAVreIHobEUUJHdesKORDo3RI2dCbW75fyJ3lB85f8AJ/
KJ45xsSAFE/AddMijqYTfOPNcFQ07lLxI3FWSkiQiiHKIccA80+Dg5BPdG4zQXEV
ufM6Mwv+nVkCRmJtn5kUixUH1taTimNVZHxXaRhZnQEvHInB8lxujSuvjsnJZkrG
hhIyFNuVkg+W/gQ6X28asytj3uWTwyu+CtfrIoNm8lEARJ/3rhxRVt9nHuyYYWsD
awz2wiv4Lbgglld1A744jSwuXJ4vh17wQKIfnOTZuE4s1ZFFqfQmkRr20JrG/7TH
p3q1yQbdoBeHjW9Rbc0Quakmzc1csQ==
=Q/n+
-----END PGP SIGNATURE-----

Hi Mark,

Thanks for your feedback; Alright I have not done any upload to
unstable. I see you uploaded a version with the fix applied, thank
you!

Regards,
Salvatore