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